On Tue, 2002-02-19 at 06:11, Igor Sysoev wrote:
> On Tue, 19 Feb 2002, [iso-8859-1] Nicholas Oxhøj wrote:
>
> > > if mod_deflate will receive flush request it will flush
> > > deflate encoding
> > > and will write compressed content to Apache buffer. But it does not
> > > flush Apache. Anyway the max block is 8K, Apache buffer is 4K and OS
> > > usually should send data if in OS's buffer there is more then 2K.
> > > So it's probably MSIE feature as well as NC4 can not render tables
> > > until it receive '</table>'.
> >
> > If it was a "bug" in MSIE, it must be something specifically related to receiving
>compressed content, since the same data sent uncompressed, gets rendered as they
>arrive.
> >
> > Anyway, I just tried getting the same data using lynx, and this made it evident
>that *without* mod_deflate, the data gets sent by Apache as they are ready, whereas
>*with* mod_deflate, all the compressed data are sent as one big block at the end.
>
> 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.
>
> > So it seems that I am still unable to get the functionality I am looking for.
>
> 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 valueable.
I did some experiments using Ethereal to capture the IP stream between
my browser and rambler.ru. On an example request, the timing was:
0.000 Initiate connection
0.245 Acknowledge connection
0.245 Request sent
0.530 Response receieved
0.540 Response continued
0.823 Response continued
0.826 Response finished
It is difficult to tell from these timings whether the response was sent
in steps or not. A useful test script would do something like
for 50 times:
sleep one second;
print 1KB;
-jwb
