CloudFront documentation状态:
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).
为什么 CloudFront 不在压缩前保存文件的 ETag 并将其用于原始请求，以允许 304 代码？
最佳答案
文档的相应部分已更新。
如果您的来源确实包含强 ETag(例如 S3 包含)并且 CloudFront 会压缩内容(如果它被配置为这样做，例如对于文本或 json)，它会根据要求规范(参见第 13.3.3 节。rfc2616-sec13)削弱了 ETag(例如，"foobar" 变为 W/"foobar")并且将其传递给观众。
可以存储它并稍后将其用于条件请求(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.
关于amazon-web-services - 为什么 CloudFront 无法在压缩前保存 ETag？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/52373947/