Re: [Lynx-dev] Bug#673452: lynx: does not handle all Content-Encodings advertised in Accept-Encoding

[Thorsten Glaser]

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
>different)

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.)

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