Martin Bähr <[EMAIL PROTECTED]> writes: > is anyone here able to access www.consortiuminfo.org/standardsblog/ through > wwwoffle? i keep getting this message below, and i just don't get why they > would block a proxy, and also how they detect something anyways.
I can verify that WWWOFFLE is blocked by this blog and some others because of the set of headers that it sends. The script that is doing the blocking is called "bad behaviour" and it has been around for a while. When requesting a non-persistent connection and chunked encoding (which is a valid combination in HTTP/1.1) WWWOFFLE sends the headers: Connection: close TE: chunked In discussion with the author of the bad behaviour script he said this (it is a couple of years old now): : Yes, the correct Connection: header that wwwoffle should be sending : is "Connection: TE, close" (or "Connection: close, TE") when : requesting chunked data. This would be a bug in wwwoffle. Reference: : RFC 2616, section 14.39: : : The TE header field only applies to the immediate connection. : Therefore, the keyword MUST be supplied within a Connection header : field (section 14.10) whenever TE is present in an HTTP/1.1 message. : : The test is in Bad Behaviour because several malicious proxy servers : manage to screw this up, while browsers get it right. :) This is a silly requirement since the TE header can only apply to a single connection (not an end-to-end link) and adding it to the Connection header doesn't add any new information. The problem is that if I change WWWOFFLE to send the header "Connection: TE, close" to all servers when requesting chunked encoding then servers running IIS fail to obey the "close" part which holds open the connection. There is a work-around, so all is not lost. Just add this line to the OnlineOptions ssection of the WWWOFFLE configuration file: <http://www.consortiuminfo.org/standardsblog/*> request-chunked-data = no This will stop the chunked encoding request header being sent to the server so there is no need to put two things in the Connection header so the script won't fail. Unfortunately there seems to be a blacklist. I tried first with this option set and got in. Then I removed it again and was blocked. When I put it back I was still blocked, I don't know how long this blocking lasts for. I thought that it was so funny that a "standards blog" would block browsers for trivial reasons that I e-mailed the address on the error page. I will let you know if I get anything back. > what does wwwoffle do to the request? is it possible to make wwwoffle send out > the request exactly as it received it from the browser? If you go to the WWWOFFLE information page: http://localhost:8080/info/request?http://www.consortiuminfo.org/standardsblog/ and clink on the link you will see the headers that are sent by the browser and would be sent by WWWOFFLE. If you go to the WWWOFFLE information page: http://localhost:8080/info/url?http://www.consortiuminfo.org/standardsblog/ then you will see the headers that came back from the server and would be sent to the browser. -- Andrew. ---------------------------------------------------------------------- Andrew M. Bishop [EMAIL PROTECTED] http://www.gedanken.demon.co.uk/ WWWOFFLE users page: http://www.gedanken.demon.co.uk/wwwoffle/version-2.9/user.html
