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) On Saturday, January 14, 2017 at 7:08:55 PM UTC+1, Anmol Sethi wrote: > > 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? > -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
