httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@apache.org>
Subject Re: cvs commit: httpd-2.0/modules/filters mod_deflate.c
Date Mon, 20 May 2002 15:40:03 GMT
Cliff Woolley wrote:
> On 20 May 2002 ianh@apache.org wrote:
> 
> 
>>ianh        02/05/19 17:07:33
>>
>>  Modified:    modules/filters mod_deflate.c
>>  Log:
>>  content with "Content-Encoding" header, content is encoded.
>>  But mod_deflate does not check it. It cause to encode content twice.
>>
>>  This problem is reproducable by getting encoded content via mod_proxy.
>>
>>  Patch Contributed by kaz@asada.sytes.net (ASADA Kazuhisa)
>>  Bug #9222
> 
> 
> Whoa, wait a minute.  That doesn't strike me as the right solution.  The
> encoding should be one-hop only.  If it's encoded and we want to maintain
> that encoding, chances are we'll have to decode it and re-encode it later.

deflate runs at the end (I think it's a header/network type output 
filter)  and the output of this is compressed data.

we do check if the user can accept the gzip encoding,
i assumed that if this has been content-encoded already that module has 
done all the checks necessary to make sure the client supports it.

This should also fix the case where you have multiple content-encoders 
running on the same file.. the one with the highest priority (first in 
the chain) will do the encoding and the others will leave it alone.

I think what your after is a mod-inflate which de-compresses the data


> Why you ask?  Because leaving it encoded makes it impossible to apply
> another filter on the proxy server (eg mod_include).  Now perhaps if we
> can guarantee that there are no other filters in the chain that will want
> to modify the content *and* that the client can actually accept the
> encoding, then as an optimization we can pass the data through the filter
> chain still encoded.  But that would only be an optimization.  And it
> seems like it could be tricky to get it to always work doing it that way,
> perhaps.  (Is there ever a case where the client does not accept an
> encoding but the proxy does?)

It shouldn't .. the proxy should be fixed if it does IMHO

--Ian

> 
> --Cliff
> 
> --------------------------------------------------------------
>    Cliff Woolley
>    cliffwoolley@yahoo.com
>    Charlottesville, VA
> 
> 




Mime
View raw message