[22 hours - ping]

Votes please?  2/3 of our users use 1.3, do you?

Jim reminded me we don't ap_strtol everywhere, so the NULL check
I guess remains a good idea, as would a (len_end == content_length)
test which I will add before committing.

Bill


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