Re: HTTP/1.1 to clients in v3.2

mån 2010-08-16 klockan 11:43 -0600 skrev Alex Rousskov:

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

But the client doesn't really know.. it knows Squid. HTTP version,
transfer encoding etc is hop-by-hop, not end-to-end. Well, there is Via,
but not sent on 100 Continue for example.

Specs says "MUST include a valid Content-Length header field unless the
server is known to be HTTP/1.1 compliant".

But we should at least have a knob for tuning this. I don't really agree
with the specs here. As you note if the client sends chunked then in
reality it's quite likely the server supports chunked as the client most
likely have some out of band information about the server capabilities.

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

Not really doable. Request may be huge and buffer space limited.

I am entirely fine with dechunking and converting to content-length
should we already have the data buffered. But not to use it as default
mechanism.

Limited buffering plays somewhat badly with 100 Continue. I am not very
comfortable with sending a 411 after 100 Continue even if not strictly
illegal. Very unlikely clients deal well with such situation as specs
says the 100 Continue indicates explicitly that the origin server is
willing to accept the body.

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

This should work out reasonably well I think, but adds a fair amount of
complexity.

If we get 100 Continue then the server is supposed to be 1.1. But MAY be
an intermediary seding 100 Continue (not strictly legal..)

If we add 100-continue then we must also retry without 100-continue if
receiving a 417. Which also means that we need to buffer the request
while it's forwarded, which risks running into the same limited
buffering issue, requiring us to send a 411 response if buffer space has
been exceeded and receiving a 417 response.

> Any other options?

I don't think a single hard answer can be given. More likely a mix and
some knobs to tune to real world brokenness will be needed. But in the
short run blindly forwarding quite liekly works.

> Should the choice depend on whether we are a direct
> or interception proxy?

Not really. End result is pretty much the same, except that the client
have even less knowledge about the state of things when being
intercepted.

Regards
Henrik
Received on Mon Aug 16 2010 - 19:17:40 MDT