On 08/01/2007 11:53 AM, Joe Orton wrote: > On Sun, Jul 29, 2007 at 08:35:58AM -0000, [EMAIL PROTECTED] wrote: >> Author: niq >> Date: Sun Jul 29 01:35:56 2007 >> New Revision: 560689 >> >> URL: http://svn.apache.org/viewvc?view=rev&rev=560689 >> Log: >> Fix protocol handling in mod_deflate input filter >> PR 23287 > ... >> @@ -688,6 +718,9 @@ >> ap_remove_input_filter(f); >> return ap_get_brigade(f->next, bb, mode, block, readbytes); >> } >> + apr_table_unset(r->headers_in, "Content-Length"); >> + apr_table_unset(r->headers_in, "Content-MD5"); >> + apr_table_unset(r->headers_in, "Content-Range"); >> >> f->ctx = ctx = apr_pcalloc(f->r->pool, sizeof(*ctx)); >> ctx->bb = apr_brigade_create(r->pool, f->c->bucket_alloc); > > This bit is also broken - unsetting C-L here is wrong presumably because > the HTTP input filter no longer knows how to fetch the request body. > t/modules/deflate.t in the test suite triggers the issue; removing that > unset fixes it.
I have not investigated this further, but shouldn't the request body run through the HTTP input filter first before it runs through the inflate input filter? The request body may have a chunked transfer encoding that needs dechunking first. And the HTTP input filter only needs the Content-Length header the very first time as it stores its contents in its filter context. > > Also simply removing content-range is a semantic change, so I can't see > how that is correct. If the filter cannot adjust content-range > appropriately it should either do nothing or fail, I'd say. I agree with this. See my additional mail from today. Regards Rüdiger
