Re: [PATCH] send HTTP/1.1 requests to HTTP servers for selected requests

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Tue, 02 Mar 2010 12:34:53 +1300

On Tue, 02 Mar 2010 00:06:02 +0100, Henrik Nordström
<henrik_at_henriknordstrom.net> wrote:
> mån 2010-03-01 klockan 14:46 -0700 skrev Alex Rousskov:
>
>> in hope that it would be useful for Squids that default to HTTP/1.0 and
>> those that default to HTTP/1.1. I am not sure we will ever need to
>> downgrade to HTTP/1.0 but it is certainly possible, especially if we
>> default to HTTP/1.1 (is not such a default a violation of RFC 2616?).
>
> In what way would our client advertising itself as HTTP/1.1 to clients
> be a violation in the 3.1 code base?
>
> We can't yet advertise ourself as HTTP/1.1 to clients, due to many small
> things such as chunked encoding, 100 relaying etc missing, but this is
> of little effect on what version we advertise our client as.
>
>> > I've thought something like
>> >
>> > no_http_version_upgrade <number> <acl-list>
>>
>> Please do not add no not positive options. No_cache was confusing
enough
>> :-).
>
> Agreed.
>
> What about
>
> http_version <number> <acl..>
>
> plus for trunk similar http_version= option to http(s)_port but without
> acl..
>
>> > But don't really seen the need for it yet. The brokenness seems to be
>> > all in servers wanting a higher version sent to them. Not a lower.
>>
>> Right, but this could be because we are not sending higher versions
yet.
>
> The only things I know of seen with 2.7 running with HTTP/1.1 on both
> sides have been
>
> - 417 broken clients
> - chunked encoding in requests
>
> But then 2.7 also filters forwarded requests somewhat. Mainly Expect and
> TE IIRC.
>
> but the available test data is admittedly not very huge, just a couple
> of minor ISPs..
>
>
> The 417 brokenness is not related to which protocol version we announce,
> but just broken clients not prepared to deal with unfulfilled
> expectations..
>
> If we do nothing about Expect then we will behave the same as Squid-2
> configured with "ignore_expect_100" which is the way we currently
> behave.. change of protocol versions do not change this aspect at all.
>

The only risk I can really see is with compliant servers. If they see us
as 1.1 relaying an Expect: there is a reasonably high risk they might
actually try to use it. As they should.

They way we are expected to handle this as you well know is issuing 417 on
inputs. So they are linked, but loosely.

Amos
Received on Mon Mar 01 2010 - 23:34:57 MST

This archive was generated by hypermail 2.2.0 : Tue Mar 02 2010 - 12:00:04 MST