should every .gz file be served with content-encoding gzip?

[Anmol Sethi]

Say in my http fileserver, I have /static/foo.tar.gz. Should my fileserver be serving it as /static/foo.tarwith content-encoding: gzip always or should it be served as /static/foo.tar.gz with content-type: gzip?

Change foo.tar.gz with any file that ends in .gz. My question boils down to whether or not every .gz file should be served with content-encoding: gzip? I know it's fine for html/css/js but I'm wondering if there are some files, where i should be serving them with content-type: gzip? As in, why not just always use content-encoding: gzip and strip off the extension?

[Andy Balholm]

It all depends on what the user wants to have when they are done downloading. In the case of HTML, CSS, and JS, they want an uncompressed file that is ready for their browser to use. So you should use Content-Encoding: gzip and Content-Type: text/html or whatever. In the case of a .tar.gz, they may be expecting to find a tar.gz file in their downloads folder, so you should use Content-Type: application/gzip (not just gzip).

But rather than trying to guess what the user wants, you can go by the filename in the request. If the request specifies a filename ending in .gz, use Content-Type: application/gzip; if your server is adding the .gz, use Content-Encoding: gzip. (And check the Accept-Encoding header too.)

Andy

[mhh...@gmail.com]

Say you have this foo.tar.gz,
served as /foo.tar.gz with a content-encoding: gzip,
the browser would in fact decode the gzip stream and serve a tar file.

I guess, it is unexpected,
the content-encoding should probably be application/octet-stream
to instruct the browser to download the file,
for correctness the content-type should be application/x-gzip

Now lets say you are serving pre-compressed some.css.gz,
you d better serve it as some.css,
when the request comes in,
check the accept-encoding header of the request,
- if it says gzip, set the response header content-encoding to gz,
read the gz file straight.
- if the accept header of the request says to not handle gzip,
serve an uncompressed version of this gz (maybe you read it straight form the file system too?).

in both case, set the response content-type appropriately for the file
type (in that case text/css, and certainly not application/x-gzip)




[Anmol Sethi]

While it is unexpected, what is wrong with just serving a tar file and redirecting a foo.gz request to a foo request? Why should a user want to have a .gz file after downloading?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andy Balholm]

1. It is unexpected. When I click a link that ends with .tar.gz, I expect to get a .tar.gz file.

2. It is a waste of disk space. Sure, as soon as they download the tarball, they will extract it. But they still need the space for both the tarball and the contents at the same time. So we might as well let them conserve space if they want to.

3. Some programs don’t accept uncompressed .tar files; they require .tar.gz.

On Jan 14, 2017, at 10:57 AM, Anmol Sethi <an...@aubble.com> wrote:

While it is unexpected, what is wrong with just serving a tar file and redirecting a foo.gz request to a foo request? Why should a user want to have a .gz file after downloading?

[mhh...@gmail.com]

if you do so, it will be longer to download,
it also put more pressure on the server as it needs to
decompress the content as it serves it.
Other side effects occurs such as
the longer it is to serve a request
the busier the server will be
thus the more likely you are to hit the server capacity.

Now if that really is what you want/need to do,
technically speaking you can,
have fun with it!

[Anmol Sethi]

How will it take longer to download? The gzipped version will still be transferred, just without the extension and the Content-Encoding set to gzip.