Re: [Bug-wget] New wget (1.19.2): Unexpected download behaviour for gzip-compressed tarballs (HTTP-header dependent)

[Tim Rühsen]

On 11/03/2017 09:30 AM, Daniel Stenberg wrote:
> 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.

Delegating to the user is quite elegant :-)

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

Thanks for sharing that knowledge. That puts Jens' input into a
different light. We'll add a patch to work with both kinds of server
behavior.


With Best Regards, Tim

signature.asc
Description: OpenPGP digital signature