> What mod_deflate did you try ? My or Apache 2.0 ? Yours > I can comment my mod_deflate. > First, mod_deflate did not collect all output before compressing - it > compress it on the fly. But it emits compressed content in 8K block. > It's Apache's HUGE_STRING_LEN #define and it can be changed > in sources. > Besides if some module flushes output then mod_deflate would > flushed it too. > > mod_deflate did not have problems with chunked transfer-encoding > because it compress content before Apache start to make chunks. > mod_deflate remove Content-Length header so compressed content > would be sent to client chunked (HTTP/1.1) or not (HTTP/1.0).
At the moment I have made my mod_perl handler extra slow, so that it is easier to see the effects of the different compression modules. The handler returns approx. 430KB of uncompressed HTML. With no compression module, the HTML slowly trickles to the browser, and the data gets displayed/rendered as it arrives. With mod_deflate enabled, nothing gets displayed in the browser until all 24KB of the gzip compressed HTML has arrived at the browser. Unfortunately I don't really have the tools to see when data are received at the client side, I can only judge by the time they are displayed/rendered in the browser. So I can't really tell if the problem is, that all the data are received in one big batch or if they are actually received in 8K blocks, but some bug-like feature in IE 5.5 makes it unable to decode the gzipped data in a "streaming" fashion as they arrive. Nicholas Oxhøj
