: How should I reference precompressed versions of static files hosted with Amazon's S3? I have a website that serves static assets (CSS, JavaScript, images) directly from Amazon's S3. As far as

@Sims2060225

Why do you want to serve those static assets with a gz extension at all?

Despite being the common indicator for ages, file extensions are actually an inferior and inaccurate mechanism to communicate a MIME type in the first place: ideally, web resources should be entirely agnostic to file extensions and only communicate their content by means of appropriate HTTP headers like Content-Type and Content-Encoding (which by the way eases maintaining an URI space as well - Cool URIs don't change ;)

Granted, this has not worked in the early days of the internet, and might still not work with a few inferior clients (annoyingly some proxies and weaker mobiles seem to suffer from this still), but unless you can clearly identify a relevant portion of your audience being affected from this limitation (and nudging them to upgrade their browser eventually is not an option), you should probably start to simply trust the HTTP headers in use instead.

Consequently I'd simply serve the static assets pre-compressed with the Content-Encoding and (to address your last question) the equally important Content-Type headers (else clients would indeed need to infer the media type from the extension and/or the content itself), but without the gz extension, as discussed in Skyler Johnson's answer to Serving gzipped CSS and JavaScript from Amazon CloudFront via S3.

Obviously, once you rely on Content-Type and Content-Encoding, this should work just as well, if you'd serve it with gz.css (or no extension at all for that matter), however, as outlined above, this might actually turn out to be misleading to downstream clients, insofar they do not not necessarily have to deal with an gzip encoded file anymore (a proxy might have decoded it already for example).

Vote Up Vote Down