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
Received on Fri Sep 03 2010 - 17:45:59 MDT
This archive was generated by hypermail 2.2.0 : Fri Sep 03 2010 - 12:00:09 MDT