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

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?
2) Should we enable HTTP/1.1 requests by default in v3.1?
3) Should we add force_http_request_version?

My suggestion is to continue discussing (1) separately, not enable
HTTP/1.1 by default in v3.1, but add force_http_request_version to v3.1
(and to the trunk).

What do you think?

Thank you,

Alex.
Received on Tue Mar 02 2010 - 05:04:05 MST