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

On Mon, 01 Mar 2010 14:46:44 -0700, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 02/22/2010 01:28 PM, Amos Jeffries wrote:
>> Tsantilas Christos wrote:
>>> Henrik Nordström wrote:
>>>> To my understanding our HTTP client is fairly complete wrt HTTP/1.1
>>>> requirements.
>>>
>>> We are supporting chunked encodings, and HTTP 1.1 persistent
>>> connections.
>>> Looks that most of the HTTP 1.1 new features are not used if the HTTP
>>> client does not ask them.
>>> Looks that you have right but I did not check very carefully the rfcs.
>>>
>>> Maybe the force_http_1p1_request should implemented as
>>> force_http_1p0_request :-)
>>
>> Yes :) Or something similar.
>
> While I do understand the logic, and agree with the overall direction of
> this discussion, the specific proposed feature is needed for some ISP
> deployments [of Squid 3.1]. If we are not going to default to HTTP/1.1
> in Squid 3.1, then we can just add this feature there and not to the
> trunk. This will require Amos' approval.
>
> Alternatively, we can rewrite this to become:
>
> force_http_request_version <version> <acl>
>
> 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?).
>
>> 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
> :-).
>
>> Being an HTTP violation, which stops Squid upgrading matching requests
>> beyond <number> when the ACL match.
>>
>> 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.
>
> Thank you,
>
> Alex.

I have an overwhelming urge to go with just advertising 1.1 to servers,
1.0 to clients and follow the spec about 417. Screw the broken clients.

Shall we agree on that much now please and then figure out what hacks to
plug in to screw the broken clients less badly?

We have a couple of options on hacks:
 * the forced downgrade option
 * stripping Expect: headers on requests (by skipping 417 abort plus
"request_header_access Expect deny all")
 * ignoring Expect: headers and stripping the 1xx replies. (as per 2.7
ignore_expect_100)

Amos
Received on Mon Mar 01 2010 - 22:17:41 MST