Mailing-List: contact modperl-help@apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 20 Feb 2002 12:44:27 +0300 (MSK)
From: Igor Sysoev <is@rambler-co.ru>
To: =?iso-8859-1?Q?Nicholas_Oxh=F8j?= <nicholas-modperl@oxhoej.dk>
cc: modperl@apache.org
Subject: Re: "Streaming" compression of output from mod_perl handler?
In-Reply-To: <005101c1b9dd$32d782a0$100e0a0a@niox>
Message-ID: <Pine.BSF.4.21.0202201238520.32336-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=KOI8-R
Content-Transfer-Encoding: 8BIT

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