On Tue, Oct 30, 2018 at 12:06:15PM +0000, Kartikaya Gupta wrote:
> On Tue, Oct 30, 2018 at 10:14:06AM +0100, Dan Fandrich wrote:
> > Any script that downloads compressed tar balls will suddenly start breaking on
> > many servers if curl starts silently decompressing them. Many servers mark
> > these with Content-Encoding: gzip so this is a very common case, I would guess.
> > I'd say that having it on by default would probably make more sense if it
> > weren't for this.
>
> Are you referring to tarballs that are already compressed (e.g. foo.tgz

Yes.

> or foo.tar.gz)? If so, the server should only be marking it
> 'Content-Encoding: gzip' if the the tarball is double-compressed. If it
> is sending the raw foo.tgz bytes with a 'Content-Encoding: gzip' that
> sounds like a server bug.

I wouldn't call it necessarily a bug—the file is gzip compressed and the
contents need to be uncompressed to make use of it, so Content-Encoding: gzip
isn't prima facie wrong. It's just that many clients would prefer to keep the
file compressed in order to save it to disk intact. But consider a web
application that, for example, lets you list the directories of tar balls given
the URL of one on the web. For such a client, Content-Encoding: gzip makes
sense as the data it needs is in tar format, not gzip format.

Regardless, many servers do this and we need to keep in mind the ramifications
of changing the default curl behaviour.
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-10-30