Thorsten Glaser wrote:
Thomas Dickey dixit:
According to the trace log, the server sent "Content-Encoding: gzip"
in the response header in both cases. I think the client should
store uncompressed files in these cases.
hmm - just ".tar" ?
(but then the server would not provide bzip2...)
No.
What he means (I think — I occasionally experience a similar problem)
is that content served with a “Content-Encoding: gzip” header should
be decompressed by lynx before being saved by the (D)ownload process
(or passed to a DOWNLOADER utility).
The "Content-Encoding" gzip is a feature of many web-server software
packages. Your client would automatically uncompress it before
storing it. This is independent of any file format.
In general gzip doesn't compress as well as bzip2 or xz. I'm not
sure how it compares to zip off hand -- suspect they are similar.
It's also the case that the server compressing the transmission stream
is usually unrelated to what is being sent. I.e. the server knows
nothing about bzip, zip or xz -- it just sees data that it tries to
compress with a low-cost, on-the-fly compression algorithm.
_______________________________________________
Lynx-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lynx-dev
