Re: [PATCH] chunked requests

On 07/13/2009 05:40 AM, Henrik Nordstrom wrote:
> 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.

Agreed.

> 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..

Agreed.

Please note that this was a short-term hack to handle most chunked
requests that we should not even receive. It can be improved to handle
more kinds of chunked requests correctly, but it may be better to focus
on the long-term fix instead. The above caveats do apply to that
long-term work.

> 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.

Have you shared your opinion on the practicality of that MUST with the
2616bis folks? It looks like the specs should be adjusted if others
agree with the "client knows better" point of view in the proxy context.
This would certainly simplify the long-term fix.

Thank you,

Alex.
Received on Mon Jul 13 2009 - 14:14:51 MDT