Re: [Bug 3034] HTTP/1.0 chunked replies break Firefox
ons 2010-09-01 klockan 22:54 + skrev Amos Jeffries: 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. You either dechunk or reject the request. There is no middleground in request forwarding. 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? No. HTTP do not work like that. HTTP requests only have two possible message delimiters: a) Content-Lenght with a known length. b) Chunked encoding TCP/FIN is only used on replies, not requests. HTTP is very clear on what is the standard order of operation when forwarding requests, and is to reject chunked request with 411 Length Requires if it's not known the request can safely be forwarded using chunked encoding, else forward it using chunked encoding. Dechunking is a deviation from protocol specifications and not how HTTP/1.1 is supposed to operate. Allowed, but by far the default intended mode of operation. In HTTP/1.1 everyone is supposed to support chunked encoding. Also, when HTTP/1.1 (2616) operates the way it's designed (Expect: 100-continue) then you won't even get the request data until an 100 Continue have been seen, and having a proxy send 100 Continue only so that it can dechunk the request is again not how 100 Continue is meant to be used. 100 Continue is really meant to be end-to-end avoiding to transmit the request body until it's known the target server want's to see it. It's not forbidden to use it hop by hop but logics on forwarding 100 Continue responses and/or the request body gets a little muddy when intermediaries insert 100 Continue messages. As I see it the collateral damage of lost connections is unpleasant but no worse than in HTTP/1.0. ? Regards Henrik
Re: [Bug 3034] HTTP/1.0 chunked replies break Firefox
ons 2010-09-01 klockan 21:52 -0600 skrev Alex Rousskov: 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). +1 on that from me. Allows the chunked response support to evolve experimentally until we feel comfortable with announcing as HTTP/1.1. Use of chunked in HTTP/1.0 is purely experimental. 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). We have discussed that a lot already. I don't mind seeing an option for setting the HTTP version of responses. A simple per http_port on/off kind of directive as in Squid-2.7 is quite sufficient. If this is added then the chunked response version check discussed earlier is needed, to only chunk the response if our response version is HTTP/1.1. Once we do have acceptable HTTP/1.1 level compliance then the need for this tuning option should go away, making the default HTTP/1.1. I doubt there will be need for HTTP/1.0 downgrade once we can forward HTTP/1.1 properly. Regards Henrik
Re: [Bug 3034] HTTP/1.0 chunked replies break Firefox
Alex, 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. 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. 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. Amos
Re: [Bug 3034] HTTP/1.0 chunked replies break Firefox
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.
