Witold Filipczyk <wite...@poczta.onet.pl> writes:

> Sorry, but the server sends in header: Content-Encoding: gzip,
> but the first chunk is not compressed.

You're right.  I suppose we should (1) try to get the server bug
fixed and (2) implement some workaround in ELinks.

For (1), it would be good to know whether the bug is caused by
some local configuration at www.eweek.com, or also present in the
standard Apache 1.3.37 distribution.  However, the response
headers don't list any extra modules, and I don't see any
bug-reporting address at the eWEEK or Ziff Davis Enterprise web
sites where we could ask how they have configured their server.
Perhaps someone at Apache might remember such a bug?

For (2), ELinks should preferably detect decompression errors and
blacklist the server and retry without Accept-Encoding (if the
connection is retryable).  Until that is implemented, it seems
best to set protocol.http.compression = 0 by default.

Attachment: pgpzteNhInjmL.pgp
Description: PGP signature

elinks-dev mailing list

Reply via email to