httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject [vote(s)] [Patch 1.3] Strict proxy C-L / T-E conformance
Date Fri, 08 Jul 2005 04:27:18 GMT
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?

View raw message