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

From: Amos Jeffries <>
Date: Tue, 02 Mar 2010 21:23:50 +1300

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
>> 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.


Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE24
   Current Beta Squid
Received on Tue Mar 02 2010 - 08:24:09 MST

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