Re: Proposal to change default handling for content-encoded responses
Date: Thu, 1 Nov 2018 16:53:52 +0100
# 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.