On Nov 17, 2007 9:36 AM, <[EMAIL PROTECTED]> wrote:
> Author: niq
> Date: Sat Nov 17 06:36:58 2007
> New Revision: 595954
>
> URL: http://svn.apache.org/viewvc?rev=595954&view=rev
> Log:
> Safer fix to PR43882 than in r595672.
>
> Modified:
> httpd/httpd/trunk/modules/http/http_filters.c
>
> Modified: httpd/httpd/trunk/modules/http/http_filters.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http/http_filters.c?rev=595954&r1=595953&r2=595954&view=diff
> ==============================================================================
> --- httpd/httpd/trunk/modules/http/http_filters.c (original)
> +++ httpd/httpd/trunk/modules/http/http_filters.c Sat Nov 17 06:36:58 2007
> @@ -115,11 +115,11 @@
> lenp = apr_table_get(f->r->headers_in, "Content-Length");
>
> if (tenc) {
> - /* RFC2616 allows qualifiers, so use strncasecmp */
> - if (!strncasecmp(tenc, "chunked", 7) && !ap_strchr_c(tenc, ','))
> {
> + if (!strcasecmp(tenc, "chunked")) {
> ctx->state = BODY_CHUNK;
> }
> - else {
> + /* test lenp, because it gives another case we can handle */
> + else if (!lenp) {
> /* Something that isn't in HTTP, unless some future
> * edition defines new transfer ecodings, is unsupported.
The overall flow now looks like:
if Transfer-Encoding {
if Transfer-Encoding == chunked {
respect it
}
else if no Content-Length {
log it and return an error
}
else {
UNHANDLED case with unrecognized Transfer-Encoding as well as
Content-Length
}
}
else if Content-Length {
respect CL
}
What is the intention for the UNHANDLED case? The code/comments
seem to imply we'll end up in the "respect CL" path.
