On 09/07/11 04:13, David Salisbury wrote:
> > "headers: 'GET http://www.server-im-trying-to-get-to.com/ HTTP/1.1" > squidclient only shows the headers between itself and Squid. Not the headers > on the other side of Squid. But doesn't that GET request above (which I made squidclient print with the -v flag to see squid's initial request) mean that it's "asking" in HTTP/1.1? Wouldn't that request end with HTTP/1.0 if it was just asking in 1.0? Or do I misunderstand something fundamental?
Yes, it does mean _squidclient_ is asking in HTTP/1.1. Just like all modern browsers do. Squid is required to change the version tag on outgoings to its highest supported one. Which for 2.7 is HTTP/1.0. Which is where the below comments come in...
> Squid-2.7 does not send HTTP/1.1 to servers unless you explicitly > configure it by adding the "http11" option on cache_peer. OK, noted, thanks. > Squid-2.7 will also drop 100-continue responses as they arrive. So I guess that's what is breaking the connection, the 100-continues being dropped. So, what I'm being told by the support at the remote site is that the reason it's sending 100-continues to me is because the client on MY side is making its request in HTTP/1.1. So their server is obliging, and thus sending back a command which I can't process (or, that I will drop) on this end and breaking the connection. So it seems, at least according to them and to what I can tell, that squid IS asking in 1.1, or something in the request is maybe making their side think that it is, anyway. BUT, I do see at http://wiki.squid-cache.org/Http11Checklist that, according to the docs, Squid is NOT asking in 1.1 and WILL not ask in 1.1 until it is fully compatible. So that seems to be out (although not third party tested, according to the link, fwiw). So why is this remote site thinking I'm 1.1 compliant??
To track and verify. The easy way is to tcpdump the traffic from Squid to the service and see what the GET look like after Squids changes it. Or the hard way is to set debug_options 11,9 and look for the headers sent out by Squid to that service.
You can also see from the same traces what the server is sending back to Squid. If you want any help interpreting please post request and reply.
> To "fix" 100-continue problems the only solution is to enable the HTTP/1.1 > feature handling of Expect: headers. 2.7 has enough support enabled by > default with the ignore_expect100 directive being turned OFF to drop the > Expect: header out of transactions and "fix" any problems it would have caused. Well, it seems the default for ignore_expect100 is what I want, based on http://www.squid-cache.org/Doc/config/ignore_expect_100/. So it seems there are three possibilities: 1) Something in the squid request is making it "seem" like it's asking in 1.1 or 2) Something on the remote side I'm connecting to is incorrectly deciding that I am 1.1 compliant or 3) The remote side is only HTTP/1.1 compliant and so I am out of luck. :/ I may have to talk more with the remote side of things unless you, Amos, or anyone else has any thoughts or suggestions. Thanks for all of your input so far! David
Amos -- Please be using Current Stable Squid 2.7.STABLE9 or 3.1.14 Beta testers wanted for 3.2.0.9
