4 ms·

I would think that any CDN would support gzipping, assuming you can set the content headers explicitly.

by mumrah 16y ago

byoung2 16y ago
Amazon Cloudfront doesn't, but there are workarounds like this: http://blog.kenweiner.com/2009/08/serving-gzipped-javascript-files-from.html http://blog.kenweiner.com/2009/08/serving-gzipped-javascript...
- mumrah 16y ago
  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-s3/ http://mumrah.net/2009/05/serve-gzipped-content-from-amazon-...
- JangoSteve 16y ago
  I explained why this doesn't work well in the part of the OP article entitled "solutions that don't work".
  - byoung2 16y ago
    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.
    - JangoSteve 16y ago
      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.
      - byoung2 16y ago
        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)})
        JangoSteve 16y ago
        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.
        byoung2 16y ago
        I'd be willing to bet that Amazon starts offering on the fly gzip within a year's time
        cloudberryman01 16y ago
        Check out our blog post on how you can enable gzip for CloudFront using the GUI tool http://blog.cloudberrylab.com/2009/07/how-to-lower-your-amazon-s3-bills-with.html http://blog.cloudberrylab.com/2009/07/how-to-lower-your-amaz...

I would think that any CDN would support gzipping, assuming you can set the content headers explicitly.

by mumrah 16y ago

I would think that any CDN would support gzipping, assuming you can set the content headers explicitly.

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

mumrah 16y ago
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-s3/ http://mumrah.net/2009/05/serve-gzipped-content-from-amazon-...
JangoSteve 16y ago
I explained why this doesn't work well in the part of the OP article entitled "solutions that don't work".
- byoung2 16y ago
  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.
  - JangoSteve 16y ago
    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.
    - byoung2 16y ago
      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)})
      - JangoSteve 16y ago
        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.
        byoung2 16y ago
        I'd be willing to bet that Amazon starts offering on the fly gzip within a year's time
        cloudberryman01 16y ago
        Check out our blog post on how you can enable gzip for CloudFront using the GUI tool http://blog.cloudberrylab.com/2009/07/how-to-lower-your-amazon-s3-bills-with.html http://blog.cloudberrylab.com/2009/07/how-to-lower-your-amaz...