HTTP/1.1 to clients in v3.2

On 05/01/2010 09:34 PM, Henrik Nordström wrote:

> I am not very comfortable with enabling 1.1 by default towards clients
> until
>
> - 1xx can be handled& signalled properly
>
> - server version cache implemented, enabling us to gett rid of most
> 411& 417 cases
>
> - forwarding of chunked requests supported, with optional time& size
> limited buffer + dechunk done after access controls (not before as
> today). Primarily to avoid most 411 conditions if the next hop is of
> unknown version.

I am revisiting this issue in hope to enable HTTP/1.1 to clients. If
Squid properly dechunks requests on the client side, what should happen
to that dechunked request on the server side? Let's start with the most
general case were we do _not_ know the origin server version and where
there are no matching ACLs to control Squid behavior. I see several options:

1. Always send a chunked request (because the client did so and perhaps
the client knows that the server is HTTP/1.1 and can handle a chunked
request.)

2. Always send dechunked request with a Content-Length field, after
buffering all the chunks and calculating content length (because we do
not know whether the server is HTTP/1.1 and can handle a chunked request).

3. Always add an "Expect: 100-continue" if not already there, send the
headers, and then pick option #1 or #2, depending on the server version
if we get a 100 Continue response.

Any other options? Should the choice depend on whether we are a direct
or interception proxy?

Thank you,

Alex.
Received on Mon Aug 16 2010 - 17:44:04 MDT