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 }
-----------------------------------------------------------------
md5sum:
759ed239c8364afc037c8ab486b55f1f COPYING
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.
(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.
I think it would be best to do (c) in 0.12.GIT and (d) in 0.13.GIT.
pgpxggbir0KM6.pgp
Description: PGP signature
_______________________________________________ elinks-dev mailing list [email protected] http://linuxfromscratch.org/mailman/listinfo/elinks-dev
