On Nov 11, 2007 7:44 AM, Nick Kew <[EMAIL PROTECTED]> wrote: > 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.
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 headers. > > * 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).
