Webmasters Stack Exchange is a question and answer site for pro webmasters. It only takes a minute to sign up.
Sign up to join this community
I have a website that serves static assets (CSS, JavaScript, images) directly from Amazon's S3. As far as I know S3 does not support gzip even when browsers accept it.
What problems might arise if the HTML page links to pre-compressed style_v1.gz.css and script_v1.gz.js (instead of without gz) when the application sees gzip in the Accept-Encoding request headers?
And do I need to set any special headers on these files in S3? (other than the obvious Content-Encoding: gzip)
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).
