Re: [PATCH] chunked requests

ons 2009-07-08 klockan 00:34 +0300 skrev Tsantilas Christos:
> Hi all,
> Alex ask me to separate chunked request patch from icap access
> logging patch as requested by Amos.
>
> This is the chunked request patch developed by Alex.

>From reading the patch there is a couple of problems:

a) Nothing of this should be unique to POST/PUT. HTTP message format is
the same for all requests. For what it's worth even a GET/HEAD requests
MAY contain a meaningless chunked entity.

b) seems it mishandles Transfer-Encoding somewhat. It needs to
explicitly check for the single value "chunked", and barf if there is
any other encoding applied, not just check if "chunked" is part of the
list of encodings applied. I.e. the reuqest may be encoded as "gzip,
chunked" (or even the non-conforming "chunked, chunked"). From what I
can tell from reading the code the proposed code misbehaves badly if
such requests is seen, forwarding the gzip:ed requests without any T-E
header..

In future request content-encoding should imho in general be passed as
is except for possibly unwrapping/wrapping chunked encoding internally,
optionally combined with statistics to keep track of servers not
accepting chunked and return 411 in such cases unless C-L can be
trivially added.. but such statistics is not really a MUST for this to
work even if RFC2616 is quite restrictive regarding the use of t-e in
requests. As long as we properly forward Via responses the "MUST NOT"
requirement can be rolled over on the client authors without too much
effort...

Note: Implementing the 2616 requirement strictly as written ("MUST
include a valid Content-Length header field unless the server is known
to be HTTP/1.1 compliant) isn't really an option for proxies as it would
require us to keep rather long-term statistics about each server.
Instead the only practical paths is to take the optimistic view and
assume the server supports t-e if the received request is encoded.

Regards
Henrik
Received on Mon Jul 13 2009 - 11:41:00 MDT