On 09/01/2010 04:54 PM, Amos Jeffries wrote:
The one and only known blocker to 3.1 sending HTTP/1.1 is Henriks veto.
He placed that on because the de-chunker in 3.1 required buffering the
*whole* request POST data before de-chunking or relaying on.
Working on it.
If the de-chunker could be converted to not needing the entire object
before de-chunking that would allow us to avoid half the workaround and
extra options being proposed to get the other bits working.
Can we just de-chunk requests over a certain size (8KB,16KB,?) into old
fashioned unknown-length request one chunk at a time sending out the data
and pass FIN/RST back at the end like would have happened previously? As I
see it the collateral damage of lost connections is unpleasant but no worse
than in HTTP/1.0.
The biggest problem is not with received request dechunking as such
(most of the code for that has been written long time ago and commented
out) but with properly forwarding dechunked request to servers. As we
discussed, the initial implementation may always chunk them back,
assuming the server can handle it, but the final implementation would
need to buffer or reject HTTP/1.1 chunked requests to HTTP/1.0 servers.
At this stage I'm going to pull this particular chunking patch out from
the 3.1.8 package waiting a clean fix before then.
Yes, that is an option. Those who need the feature can patch their Squids.
An alternative is to add a fast ACL option to be able to enable HTTP/1.0
chunked responses to selected user agents (none by default).
A yet another alternative is to change chunked response version to
HTTP/1.1. This would be very easy to implement, but may confuse clients
that try to track the proxy version (I suspect Opera might be doing
that, for example).
Your call which option to use, but IMHO one of the three options above
(or something of that kind) needs to be done for the next 3.1 release.
Thank you,
Alex.
