httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: unsupported compression issue seen in 2.3.5-alpha
Date Sun, 14 Feb 2010 19:53:12 GMT
On Sunday 14 February 2010, Rainer Jung wrote:
> AFAIK the discussion on the tomcat users list indicated, that the 
> problem was for some time reproducible with the eu mirror, but not
>  with  the us mirror. The reproduction did not work always but
>  roughly about every third or fourth attempt. Unfortunately I
>  didn't experience the problem myself, otherwise I would've taken a
>  network dump.
> 

There is a header dump at 
http://mail-archives.apache.org/mod_mbox/tomcat-
users/201002.mbox/<4B76BB27.2050604@ice-sa.com>

When I tried that request by hand, I noticed something that I don't 
understand:

Firefox is requesting everything but the first byte ("Range: 
bytes=1-"). Httpd is responding with a compressed 206 Partial Content 
response which includes a 'Content-Range: bytes 1-3889/3890' header. 
The response then omits the first byte of the compressed body.

But in mod_deflate.c in deflate_out_filter(), there is a check that 
removes the filter if a Content-Range header is found. Why is 
mod_deflate not removed from the output filter chain? Or is it the 
intended order of the filters that mod_deflate compresses first and 
the byterange filter then cuts out the required ranges. If yes, why do 
we have the check in mod_deflate?

I am not sure that this is actually related to the reported problem. 
But maybe firefox is expecting everything but the first byte of the 
uncompressed content?


Apart from that, in the error case 'unable to init Zlib', mod_deflate 
passes uncompressed content down the filter chain after having 
modified the headers. But this would result in entries in the error 
log.

Mime
View raw message