Hacker News Reader

Comment by byoung2 | Hacker News Reader

Amazon Cloudfront doesn't, but there are workarounds like this: http://blog.kenweiner.com/2009/08/serving-gzipped-javascript...

View on HN

I wouldn't call it a workaround. You gzip it and set the content-encoding

http://mumrah.net/2009/05/serve-gzipped-content-from-amazon-...

I explained why this doesn't work well in the part of the OP article entitled "solutions that don't work".

You discussed server-side rewriting, but this is client-side. If the user's browser supports gzip, then the gzipped javascript file gets read properly and sets the flag, and further requests get directed to the gzipped versions. This doesn't defeat the speed improvement of the CDN, and doesn't add much complexity to the filesystem or code.

This is quite different from reading the request encoding in PHP, Python, etc, on the server side that you mention.

No, that solution requires that the client be able to accept gzip encoding. The problem is, the server needs to be able to read the incoming HTTP request to see if "gzip" is contained in the HTTP:Accept-encoding header and only serve the gzipped version if the answer is YES (and otherwise serve the non-gzipped version). Apache and most other servers do this easily. Amazon S3 and CloudFront do not.

That article ignores this fact, and just always serves the gzipped version with the gzip header encoding, whether the client accepts it or not. This works for probably 90-95% of the time (or more), but for anyone with a non-trivial app, that's not good enough.

the server needs to be able to read the incoming HTTP request to see if "gzip" is contained in the HTTP:Accept-encoding header and only serve the gzipped version if the answer is YES

You're wrong...this can be accomplished on the client side with Javascript, without ever involving server-side code:

I upload a gzipped test file to S3/Cloudfront containing a single line that sets a flag (e.g. supportsGzip = true).

I then include that script at the top of my HTML page. If the browser supports gzip, then that file gets read correctly, and the supportsGzip variable gets properly set to true. If the browser does not support gzip, the file is gibberish, and the flag does not get set.

Throughout the rest of the file, I use that supportsGzip variable to determine which versions of other static files to load (e.g. if(supportsGzip) {document.write(script tag src = gzip path)})

Ah, I actually mis-read the article. Sorry, I'm wrong, you're right, that would work ;-)

I guess the only situation this wouldn't work would be if the user's browser supports gzipping, but doesn't have javascript enabled, but then it'll just serve everything unzipped by default, so not a big deal at all.

Also, it seems kind of a pain to have to do that if-statement throughout all of your javascripts, html, and stylesheets. But I'm sure you could probably create a javascript 1-liner that runs after everything else that just goes through and changes all the sources for you, so it might end up being even easier than our method.

I'd be willing to bet that Amazon starts offering on the fly gzip within a year's time

this increases latency.

Reply on news.ycombinator.com