# dan_at_coneharvesters.com / 2018-10-30 13:20:34 +0100:
> On Tue, Oct 30, 2018 at 12:06:15PM +0000, Kartikaya Gupta wrote:
> > 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.

i would call it a violation of http/1.1: if the request is for /foo.tgz,
the server can only send Content-Encoding: gzip iff gunzip is necessary
to arrive at the actual foo.tgz. it's perfectly ok for the server to
serve /foo as well backed by on-disk foo.tgz with the C-E: gzip header,
but we're not discussing that.

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

what would be the Content-Type response header in this case?

> Regardless, many servers do this and we need to keep in mind the ramifications
> of changing the default curl behaviour.

this does not match my experience. i do remember seeing this many years
ago, downloading a something.tar.gz with a browser, i would end up with
something.tar instead. maddening.

-- 
roman

-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-11-01