7

Is there any way to distribute JS Lib from AWS CloudFront with ETag header (for caching control) and with Compression (only for clients that support it) using S3 as origin?

As I understand I can: 1) Upload JS Lib (uncompressed) on S3, enable auto compression on CloudFront - but I lose ETag header, in this case, that means I lose ability to update quickly JS Lib on the client side

2) Upload JS Lib (already compressed) on S3: - but I lose clients that do not support compression

3) Use own Origin instead of S3 and control compression by myself: - I lose S3's hight durability and I have setup and manage Origin by myself

Is there 4th way that would not have disadvantages that I described above?

Alexey
  • 2,326
  • 5
  • 17
  • 27
  • Why would you lose the ETag in option 1? – Michael - sqlbot May 20 '17 at 03:30
  • 2
    CloudFront removes it: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/ServingCompressedFiles.html - `If you configure CloudFront to compress content, CloudFront removes the ETag response header from the files that it compresses.` – Alexey May 20 '17 at 16:09
  • 2
    So it does -- confirmed through testing. Strange, since they could have just [weakened](https://en.m.wikipedia.org/wiki/HTTP_ETag#Strong_and_weak_validation) the ETag (though I'm not sure that would have helped you). So, the next question would be whether `If-Modified-Since` isn't viable/sufficient, and the question after that would be whether you *really* care about the tiny set of browsers that doesn't understand gzip content encoding. (Me? I don't.) I think there will be a workaround once Lambda@Edge becomes available, but I hesitate to suggest it, now, since we don't know when that may be. – Michael - sqlbot May 20 '17 at 19:38

0 Answers0