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

Alex Rousskov wrote:
> On 03/01/2010 04:06 PM, Henrik Nordström 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?
>
> I think the HTTP/1.1 default for requests would be fine. My RFC 2616
> violation worries seem unfounded. Sending an HTTP/1.1 message that could
> be _misinterpreted_ by an HTTP/1.0 server would be a violation of RFC 2145:
>
> an HTTP/1.1 message sent to an
> HTTP/1.0 recipient (or a recipient whose version is unknown) MUST be
> constructed so that it remains a valid HTTP/1.0 message when all
> headers not defined in the HTTP/1.0 specification [1] are removed.
>
> This means that turning HTTP/1.1 on by default for requests may be OK
> but we should double check that we do not start omitting Connection:
> keep-alive or similar request features that are required for HTTP/1.0
> (and unknown) clients.
>
>
>> What about
>>
>> http_version <number> <acl..>
>
> I do not insist on the "force_" prefix (although I believe it has
> value), but I think this option should be request/reply specific:
> http_request_version or force_http_request_version.
>
>> plus for trunk similar http_version= option to http(s)_port but without
>> acl..
>
> I am afraid this will not work well because the exceptions are not based
> on port. They are based on client or server properties. For example,
> certain iPhone application services may require HTTP/1.1 requests.
>
>
>> 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.
>
> These complications and uncertainties bring me back to the earlier
> question: Should we default to HTTP/1.1 in Squid v3.1? My feeling is no,
> we should not, because it is too big of a change for v3.1. Those who
> fill otherwise, could always use:
>
> force_http_request_version 1.1 all
>
> provided we add such an option. And if we add such an option to Squid
> v3.1, let's add it to trunk as well. It will be useful for downgrading
> to 1.0 should we ever need that or if we fail to enable 1.1 by default.
>
> To summarize, there are three issues here:
>
> 1) Should we enable HTTP/1.1 requests by default in trunk?

Yes. Both server facing and client facing. With further discussion on
the related client-facing requirements before that goes in.

> 2) Should we enable HTTP/1.1 requests by default in v3.1?

Yes. server facing only. Requires squid-2 parity on expect. Getting onto
that right now.

> 3) Should we add force_http_request_version?

If need be, for down-grading only though. Jury still out on whether we
will need it though.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE24
   Current Beta Squid 3.1.0.17