ons 2010-09-01 klockan 22:54 +0000 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