Re: [squid-users] Is there any way to "turn off" or disable the HTTP/1.1 features of Squid?

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