perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Sysoev ...@rambler-co.ru>
Subject Re: "Streaming" compression of output from mod_perl handler?
Date Wed, 20 Feb 2002 09:44:27 GMT
On Wed, 20 Feb 2002, [iso-8859-1] Nicholas OxhЬj wrote:

> > I'm not sure that lynx can handle compressed response on the fly -
> > it uses gzip in pipe.
> > The best way to test it using netcat.
> 
> Well, lynx didn't decompress it, it just output the gzip compressed content to stdout.
As I didn't have netcat readily available on the machine, I instead put an strace on lynx,
to be absolutely sure, that it didn't receive any output until the very end - and it didn't
:-(
> 
> > I you like to test I can make patch for mod_deflate to flush Apache.
> > But if major browsers can not handle compressed content on the fly
> > it's not valuable.
> 
> That would be an interesting patch, but with approx 450KB of uncompressed HTML, I would
expect mod_deflate to receive compressible input, regardless if the content producer specifically
flushes or not. But I might have misunderstood something.
>
> Regarding the browsers ability to handle compressed content on the fly, we probably won't
know until I find a module that is able to produce such output.

Sorry again. I've just checked sources and found that if mod_deflate
received flush then it flushes both zlib and Apache.

You can try to set autoflush in perl module with $|=1;
or call $r->rflush; when you like to flush output.

Igor Sysoev


Mime
View raw message