|
From: | Daniel Stenberg |
Subject: | Re: [Bug-wget] New wget (1.19.2): Unexpected download behaviour for gzip-compressed tarballs (HTTP-header dependent) |
Date: | Fri, 3 Nov 2017 09:30:55 +0100 (CET) |
User-agent: | Alpine 2.20 (DEB 67 2015-01-07) |
On Thu, 2 Nov 2017, Tim Rühsen wrote:
How would you (or curl) handle Content-Type: application/x-tar Content-Encoding: gzip
when downloading 'x.tar.gz' or 'x.tgz' ? Save the file compressed or uncompressed ? And what if the file is (correctly) named 'x.tar' ?
Fortunately for me, curl doesn't make such decisions for the user so the question becomes moot - but it also means that it doesn't provide any guidance or help for the wget case. curl decompresses content-encoding if asked and it saves output in the file name the user asks for.
I downloaded/tested thousands of web pages and they behave as if 'Content- Encoding: gzip' is a compression for the transport. Uncompressing it 'on-the- fly' and saving that uncompressed data was the correct behavior.
Sure, because that's how HTTP clients and browsers have done for a long time now even if Content-Encoding: wasn't originally intended for it. The language in the spec still explains how it is not a transfer compression even if we can often pretend that it works that way.
-- / daniel.haxx.se
[Prev in Thread] | Current Thread | [Next in Thread] |