3
votes

The CloudFront documentation states:

If you configure CloudFront to compress content, CloudFront removes the ETag response header from the files that it compresses. When the ETag header is present, CloudFront and your origin can use it to determine whether the version of a file in a CloudFront edge cache is identical to the version on the origin server. However, after compression the two versions are no longer identical. As a result, when a compressed file expires and CloudFront forwards another request to your origin, your origin always returns the file to CloudFront instead of an HTTP status code 304 (Not Modified).

Why doesn't CloudFront save the ETag of the file before compression and use it for origin requests, to allow the 304 code?

1
As a suggestion it seems pretty obvious why it's not useful saving ETag in the cloudfront if it get compressed. So if ETag should be used to optimize the caching, cloudfront caching should not be enabled. It seems two different approaches to achieve the same thing. - dilantha111

1 Answers

0
votes

The corresponding section of the documentation was updated.

If your origin does include a strong ETag (e.g. S3 does) and CloudFront would compress the content (if it is configured to do so, e.g. for text or json), it would as required by the specification (see section 13.3.3. rfc2616-sec13) weaken the ETag (e.g. "foobar" becomes W/"foobar") and deliver that to the viewer.

One can store it and use it later for conditional requests (If-None-Match: W/"foobar").

ETag header

When the uncompressed object from the origin includes a valid, strong ETag HTTP header, CloudFront converts the strong ETag header value to a weak ETag, and returns the weak ETag value to the viewer. Viewers can store the weak ETag value and use it to send conditional requests with the If-None-Match HTTP header. This allows viewers, CloudFront, and the origin to treat the compressed and uncompressed versions of an object as semantically equivalent, which reduces unnecessary data transfer.