[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lynx-dev] Bug#673452: lynx: does not handle all Content-Encodings a

From: Thorsten Glaser
Subject: Re: [Lynx-dev] Bug#673452: lynx: does not handle all Content-Encodings advertised in Accept-Encoding
Date: Thu, 24 May 2012 17:56:14 +0000 (UTC)

Thomas Dickey dixit:

>> Putting \x1F\x8B\x08\0\0\0\0\0 (an empty gzip header) in front
>> of the received data, et voilà, it decompressed with gzip(1).
>If it's a widely-used defective function, we could always provide a
>workaround :-)

If you can detect it…

>The usual problems in this area are (defective) servers which send gzip'd
>data for deflate (I recall 2-3 instances).  A server which strips the headers
>from the compressed data makes things a little more difficult.

Right. But on the other hand, if gunzip fails, prepending
"\x1F\x8B\x08\0\0\0\0\0" and trying again would probably
work in most of these cases and fail again in others.

>gunzip is designed to replace uncompress (in addition to its more
>usual functionality) (gzip does not replace compress - they really are

In MirBSD (inherited this from OpenBSD), gzip functionality was
added to Unix compress instead, using some sort of pluggable
interface. I can provide source, if desired. I’d add xz in a
heartbeat if I had an Open Source licence for it. (Actually,
a BSDish licence, won’t add new GPL/LGPL code to base. But
as things are now, it’s unlicenced and thus best to avoid.)

  “Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool.”
                                                -- Edward Burr

reply via email to

[Prev in Thread] Current Thread [Next in Thread]