At 08:35 AM 7/7/2005, Roy T. Fielding wrote:
>
> It looks like a band-aid to me -- how does this module know that
> the server doesn't support other transfer encodings? Wouldn't
> it be better to register a set of transfer encoding filters and
> then error if none matches? Oh, never mind, this is for 1.3. +0.
Actually for 1.3, this patch is doing a couple things for the
proxy response from the origin server to the client;
*) It enforces 'chunked' as the only legitimate T-E
*) It unsets the C-L header if the T-E header is present
*) To avoid 'suspect' responses, it won't cache any response
with both a T-E and C-L header (If we used keep alive
backend connections, it would also want to close that.)
I corrected the ap_strtol result tests, based on the fact that
it's *our* strtol, and we know we will hiccup errno if we see
out of range, or no digits at all, and end_ptr is guarenteed
to be set.
Remember in 1.3 mod_proxy won't pass up a chunked request body
so that whole scenario is ignored for now. If the client (or
previous proxy hop) passes T-E, the request is rejected.
I believe this patch handles all the scenarios in 1.3, combined
with Jeff's request TE+CL patch. Further comment or specific
votes to the behaviors above are welcome. Would like to commit
tomorrow to roll a release candidate.
I am still waiting for the answer to the question; does mod_gzip
or any other 3p module we know of actually introduce an alternate
Transfer-Encoding to 1.3?
Bill