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
