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

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.
Received on Mon Mar 01 2010 - 22:15:11 MST