John Hawkinson <[EMAIL PROTECTED]> writes:
> --- src/encoding/gzip.c 2007/05/31 22:40:05 1.1
> +++ src/encoding/gzip.c 2007/06/02 22:22:20
> @@ -33,7 +33,9 @@
> static int
> gzip_read(struct stream_encoded *stream, unsigned char *data, int len)
> {
> +#ifdef HAVE_GZCLEARERR
> gzclearerr((gzFile *) stream->data);
> +#endif
> return gzread((gzFile *) stream->data, data, len);
> }
I see. The gzclearerr function was added in zlib 1.2.0.2,
released on 2003-07-13. elinks-0.12/doc/installation.txt and
elinks-0.12/INSTALL do not currently list any version requirement
for zlib.
Have you tested the resulting binary, especially with slow sites
and Transfer-Encoding: chunked? The call was added to ELinks in
commit d2b8e06f418f99c64a1a0f7ad4b3b906ced8617f:
gzip_read: always call gzclearerr
This is necessary when using a POSIX-compliant stdio implementation, which
will set the FILE error flag when input from the pipe is exhausted, causing
all subsequent reads to fail.
Can we assume that on Solaris 10 which does not have gzclearerr,
stdio does not actually set the flag? Otherwise, can we work
around the problem by disabling Accept-Encoding: gzip when
gzclearerr is not available?
I think the encoding layer in ELinks should be rewritten to avoid
stdio entirely, but I was hoping ELinks 0.12.0 could be released
first. If 0.12.GIT with this patch truncates documents but
0.11.3 does too, then the bug is not a regression and ELinks
could be released with it. So please also test 0.11.3 (or the
upcoming 0.11.4) if possible.
pgp2A8u2tlaSi.pgp
Description: PGP signature
_______________________________________________ elinks-dev mailing list elinks-dev@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-dev
