httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Re: svn commit: r593778 - /httpd/httpd/branches/2.2.x/STATUS
Date Sun, 11 Nov 2007 12:44:40 GMT
On Sat, 10 Nov 2007 21:08:37 -0500
"Jeff Trawick" <> wrote:

> > As you note, that's a non-fix for the input filter.
> > Unsetting content-length for input should move to the
> > find_code_page function (on a fixup hook).
> That would break reading the request body (assuming client used c-l).
> ap_http_filter(), which runs after the fixup hook, must see the c-l.
> I don't see a way to indicate that the Content-Length may not be
> correct.  CGIs could break.

Erm, right.  Now you spell it out, yes, that's the same issue we had
recently with mod_deflate, and my initial fix to that broke for the
same reason.

So +1 to your patch: it's the best we can do without a deeper change.

> The attached patch describes the situation more accurately and doesn't
> raise a concern unless the request actually had a c-l header.
> I haven't thought of how to get to the end of the rainbow starting at
> either
> * create a way to indicate to the handler that c-l is unknown without
> breaking the reading of the request body

Note incoming c-l much earlier in the request processing cycle,
and use that for ap_http_filter?  This would make sense for apps
that don't require c-l.

> * provide an optional filter to compute c-l (buffering up to some
> configured limit)

ISTR hacking up such a thing, then stumbling upon someone else's
implementation of same (possibly in mod_proxy, which may have to
insert a C-L for an HTTP/1.0 backend).

Nick Kew

Application Development with Apache - the Apache Modules Book

View raw message