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.
