On Tue, Jun 05, 2007 at 12:29:46AM +0300, Kalle Olavi Niemitalo wrote:
> John Hawkinson <[EMAIL PROTECTED]> writes:
>
> > Kalle Olavi Niemitalo <[EMAIL PROTECTED]> wrote on Sun, 3 Jun 2007
> > at 10:48:09 +0300 in <[EMAIL PROTECTED]>:
> >
> >> Have you tested the resulting binary, especially with slow sites
> >> and Transfer-Encoding: chunked?
> >
> > I have not...do you have a good test case?
>
> -----------------------------------------------------------------
> #! /usr/bin/perl
> use strict;
> use IPC::Open2;
>
> print <<EOH;
> Content-Type: text/plain
> Content-Encoding: gzip
>
> EOH
>
> local $| = 1;
> open PLAIN, "<", "/home/Kalle/src/elinks-0.12/COPYING" or die;
> my $pid = open2(\*GZIP, "<&PLAIN", "gzip -1");
> local $/ = \4567;
> while (<GZIP>) { print; sleep 1 }
> -----------------------------------------------------------------
> If I comment out the gzclearerr call in gzip_read, the output is
> truncated after "that is to say, a work". With different input
> files, ELinks can display garbage too. No such problems in
> ELinks 0.11.3.
>
> > Would it be sufficient to call clearerr() on the fd that
> > gzip_open() was called with? I guess it would be hairy to save
> > the fd.
>
> clearerr() needs a FILE *, not a file descriptor. And
> gzip_open() calls fdopen() itself, so ELinks never sees
> the FILE *. There is no function in zlib for retrieving
> the pointer, either.
>
> So then, there seem to be four options:
>
> (a) Just skip gzclearerr and ignore the resulting corruption.
> This would be a regression from 0.11.3.
>
> (b) Revert all the decompression changes from elinks-0.12,
> returning to what was in ELinks 0.11.3.
The old code doesn't work well everywhere, so gzclearerr was added
and then the decompression code was simplified (?).
> (c) Partially or completely disable gzip decompression on
> platforms that don't have gzclearerr. Document that ELinks
> needs at least zlib 1.2.0.2 for full support.
>
> (d) Rewrite the decompression code or at least the gzip part of
> it. I don't have an estimate on how long this would take.
> It would be too easy to slip in new bugs in this process.
>
(e) Write ELinks's gzclearerr using internals of the zlib of Solaris 10.
Check for gzclearerr in ./configure. If it fails use own function
and warn the user.
> I think it would be best to do (c) in 0.12.GIT and (d) in 0.13.GIT.
I wonder what happens when part of the gzip header is in the first chunk
and the rest in the next one.
_______________________________________________
elinks-dev mailing list
[email protected]
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
