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.
