On Sat, 10 Nov 2007 21:08:37 -0500 "Jeff Trawick" <[EMAIL PROTECTED]> 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 http://www.apachetutor.org/
