Bad Behavior is an excellent ‘profiling’ plug-in that deters most spam bots and attacks on web-based scripts, especially blogs, wikis, and forums. It uses a very detailed and sophisticated combination of checks and algorithms to create a ‘spammer’s profile’ and if a visitor to your site fits it, it’ll block them.
The algorithm is so good that there are almost no false positives, and together with a decent spam plug-in like Akismet or Spam Karma 2, you’re blog will be forever clean. But it has a problem with Opera. Most builds of Opera trigger a false alarm, leaving your blog reader-less, especially with the release of Opera 9, an excellent browser in all rights, but there is a solution.
- Download and extract Bad Behavior
- Open ./bad-behavior/common_tests.inc.php
- Comment out the code beginning from line 57 to line 60 (inclusive). It should look like this when you’re done:
/*<br /> if (array_key_exists(‘Te’, $package[‘headers_mixed’])) {<br /> if (!preg_match(‘/\bTE\b/’, $package[‘headers_mixed’][‘Connection’])) {<br /> return “582ec5e4”;<br /> }<br /> }<br /> */ - Save the file, upload the directory to your wp-content/plugins folder, activate, and enjoy!
The Technical Stuff
What we just did is disable “TE Request-Header” checks. TE request-headers are from RFC2616, section 14.39; and although we have no doubt that the authors of this wonderful algorithm had their reasons for including TE request-header checks, and that certain spam bots do indeed employ this particular header-request for TE, as far as we can tell the benefits gained by using such a check are minor.
You can view the entire RFC here. At any rate, it doesn’t matter. Bad Behavior is famous for its excellence and cross compatibility, and lack of false positives, so we feel it should stay that way – without the TE request-header checks. An ideal solution would be to implement this function as a subset of ‘Strict Mode’ which is specially designed to block more illicit traffic, but with the knowledge that it may block some legitimate users.
Nothing is wrong with this particular check. It functions properly and does not block Opera.
It does, however, block Opera users who are behind certain misconfigured proxy servers.
As such, you should fix the proxy server, as Bad Behavior is not broken.
The following comes from Opera and I have every reason to believe it is accurate:
If you disable HTTP/1.1 for proxies, that should take care of the problem.
If not, feel free to send me log entries and I’ll investigate further. Your messages did not include any log entries showing that any legitimate users had been blocked.
Hmmmmm..
Interesting post, thanks for passing that letter on.
I’m such a ‘real’ user, not behind any proxy, but I am on the RIPE network. If that is considered a proxy then that may be it – but then in that case I’d leave it, since I get much traffic from Europe – a great part of which is RIPE.
I doubt it’s RIPE, and as a matter of fact, that letter doesn’t explain too much:
i.e. why does it only happen with Opera and not IE or FF if it is indeed the proxy server at fault.
I’m an Opera user and I get this “Precondition Failed” every once in a while. Disabled my proxy server and disabled HTTP/1.1 (whatever that is) – makes no difference. All my anti-virus stuff is bang up to date.
All I want to say is that, to those sites who won’t let me in, “you lost a customer”.
Bad Behavior is indeed at fault here.
Now, granted proxies should not be passing through TE headers unless they themselves support TE (in which case the TE token would appear in the Connection header and the Bad Behavior check would catch that as correct behaviour) or if they do they shouldn’t report themselves as HTTP/1.1 (HTTP/1.0 proxies wouldn’t know any better) and Opera prudently doesn’t use TE on any connection until after that connection is shown to support 1.1.
However it was precisely because TE headers and other as-yet-unspecified headers with point-to-point semantics (as opposed to headers intended to be passed all the way through to the server and back – or to appear to have done so should the proxy serve the request with its own cache) could get written through incorrectly that RFC 2616 has the rule about insisting that it should be mentioned in the Connection header.
Hence:
1. Opera does the right thing.
2. Proxy does the wrong thing, possibly due to being built before HTTP/1.1 was finalised, more likely just a bug.
3. RFC2616 is written with foresight and therefore contains a mechanism for servers to catch this and not use the transfer-encoding in question.
4. Bad Behavior deliberately undoes that foresight by blocking the requests.
Excellent post Jon..
I’ve attempted to contact Michael (the author of Bad Behavior) in follow-up a couple of times, but I haven’t been successful.
Bad Behavior blocks every single person behind a local, manual, or invisible (ISP) proxy that uses TE Headers via a client that properly supports them. This patch has been out forever now, but I guess blocking tens (hundreds??) of thousands of users isn’t enough to warrant an update. 🙁
I’ve contacted Opera with regards to this problem, hopefully the can provide further insight now that all the “cards” have been laid out on the table.