httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick" <>
Subject Re: svn commit: r593778 - /httpd/httpd/branches/2.2.x/STATUS
Date Sun, 11 Nov 2007 13:35:22 GMT
On Nov 11, 2007 7:44 AM, Nick Kew <> wrote:
> 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.

Thanks for the extra thinking and review!

> > 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.

Noting c-l earlier is part of it.  I would distinguish between the
cases "apps that require c-l present" vs. "apps that require accurate
c-l" however.  (I'm hoping you'll correct me on this ;) )  Currently,
the mere presence of t-e or c-l in r->headers_in is the way a module
determines if there is a request body.  Unsetting it at any stage is
going to confuse some module somewhere even if it doesn't require an
accurate c-l.  It seems that for 2.4/3.0 we need to provide more
formal APIs for modules to use in lieu of checking for t-e or 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).

Providing a filter to compute c-l seems to have a role in helping one
glitch or another.

Perhaps this hypothetical filter in combination with a run-very-first
handler could pre-read the request body and calculate the final c-l so
that the real handler checking c-l would find the proper value
(assuming the body isn't too large to buffer).

View raw message