11

I've created a static website that is hosted on a S3 Bucket. My asset files (css and js files) are minified and compressed with gzip. The filename itself is either file_gz.js or file_gz.css and is delivered with a Content-Encoding: gzip header.

So far, I've tested out the website on various browsers and it works fine. The assets are delivered with their compressed versions and the page doesn't look any different.

The only issue that I see is that since this is a S3 bucket, there is no failsafe for when the the client (the browser) doesn't support the gzip encoding. Instead the HTTP request will fail and there will be no styling or javascript-enhancements applied to the page.

Does anyone know of any problems by setting Content-Encoding: gzip? Do all browsers support this properly? Are there any other headers that I need to append to make this work properly?

matsko
  • 21,895
  • 21
  • 102
  • 144

2 Answers2

14

Modern browsers support encoded content pretty much across the board. However, it's not safe to assume that all user agents will. The problem with your implementation is that it completely ignores HTTP's built-in method for avoiding this very problem: content negotiation. You have a couple of options:

  1. You can continue to close your eyes to the problem and hope that every user agent that accesses your content will be able to decode your gzip resources. Unfortunately, this will almost certainly not be the case; browsers are not the only user-agents out there and the "head-in-the-sand" approach to problem solving is rarely a good idea.

  2. Implement a solution to negotiate whether or not you serve a gzipped response using the Accept-Encoding header. If the client does not specify this header at all or specifies it but doesn't mention gzip, you can be fairly sure the user won't be able to decode a gzipped response. In those cases you need to send the uncompressed version.

The ins and outs of content negotiation are beyond the scope of this answer. You'll need to do some research on how to parse the Accept-Encoding header and negotiate the encoding of your responses. Usually, content encoding is accomplished through the use of third-party modules like Apache's mod_deflate. Though I'm not familiar with S3's options in this area, I suspect you'll need to implement the negotiation yourself.

In summary: sending encoded content without first clearing it with the client is not a very good idea.

  • Thank you for your detailed post. Is there any way to have a redirect `location: ...` for a unaccepted content-encoding? – matsko Aug 28 '12 at 18:16
  • 1
    That's not how content-negotiation works -- you aren't redirecting to another version, you're determining which version of the content to serve up for that specific request. No redirection is necessary. You need to parse the value of the `Accept-Encoding` header to determine if a gzip response is supported by the client. **If** no `Accept-Encoding` header is requested, you are required by the HTTP spec to serve the resource in its native format (identity) without any additional encodings. –  Aug 28 '12 at 18:24
  • Right. But with S3 there is no content-negotiation feature. Each URL is mapped to one and only one version of the resource. So the only option I would have is to redirect the resource, but it doesn't look look like it's possible. – matsko Aug 28 '12 at 18:30
  • Like I said, I'm not familiar with S3's capabilities in this area, but it appears from [this answer over at AWS](https://forums.aws.amazon.com/thread.jspa?messageID=251627) that you would need to determine the encoding on your server and rewrite the links to return the actual content or perform a redirect to the gzipped content. Regardless of how you do it, it's important to verify that the client can accept the encoded response before you send it. –  Aug 28 '12 at 18:37
2
  1. Have you CSS / minfied CSS (example.css [247 kb]).
  2. Use cmd gzip -9 example.css and covert file will be like example.css.gz [44 kb].
  3. Rename the file example.css.gz to example.css.
  4. Upload the file into S3 bucket and in the properties click meta-data.
  5. Add new meta-data tag, select Context-Encoding and value gzip.
  6. Now your CSS will be minified and also gzip.

source: http://www.rightbrainnetworks.com/blog/serving-compressed-gzipped-static-files-from-amazon-s3-or-cloudfront/

Michał Perłakowski
  • 88,409
  • 26
  • 156
  • 177
Cyril Prince
  • 81
  • 1
  • 4