我可以禁止在 AWS Cloudfront 上发出 Etag 标头吗？
我正在使用 Amazon 的 Cloudfront CDN 来存储静态资产。 Couldfront 为每个 GET 请求发出一个 Etag。我已经使用特定的缓存控制信息为我的所有资产设置了元数据，这（据我所知）使得 Etag 变得多余。我在 WebPageTest.org 上测试了我网站的负载性能，这些不必要的 Etag 令我很烦恼。如果它们实际上是不必要的，有谁知道有什么方法可以抑制它们的排放吗？
I am using Amazon's Cloudfront CDN for static assets. Couldfront issues an Etag for every GET request. I have set meta data fro all my assets with specific Cache-Control information, which (as I understand) makes the Etag superfluous. I test my site's load performance at WebPageTest.org, and it dings me for these unnecessary Etags. If they are in fact unnecessary, does anyone know of a way to suppress their being emitted?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您使用源服务器并在源服务器上禁用 ETag，CloudFront 不会在其标头中添加 ETag。我通过在源服务器上禁用 ETag 来验证它。
If you are using an Origin Server and disabled ETag on the origin server, CloudFront would not add the ETag in its headers. I verified it by disabling the ETag on my origin server.
如果无论您从哪个节点下载资产，Cloudfront 都会提供一致的 Etag，那么这应该可以最大程度地减少问题。我通过执行以下操作对此进行了测试：
从两个不同位置解析到 Cloudfront，我验证了 CNAME 解析为完全不同的 IP 地址集。第一个服务器解析为 Amazon LAX 数据中心 (lax1.cloudfront.net) 中的一组 8 个 IP 地址，第二个服务器解析为 Amazon SFO 数据中心 (sfo4.cloudfront.net) 中的 8 个 IP 地址。
我在 Cloudfront 发行版中选择了一个对象，并从每个位置执行了“wget --server-response”，然后比较了结果。我对每个数据中心执行了多次此操作，以获取来自每个数据中心中不同 IP 地址的响应。
结果是，无论我访问哪个数据中心以及该数据中心响应哪个 IP 地址，Etag 都是相同的。
我确实注意到以下标头在服务器之间确实有所不同
x-amz-id-2
x-amz-请求 ID
年龄
X-Amz-Cf-Id
通过
希望这会有所帮助，
大卫
[编辑-根据下面的良好更正删除了对电子标签的评论]
If Cloudfront delivers consistent Etags regardless of which node you download the asset from, then this should minimize the problem. I've tested this by doing the following:
Resolving to Cloudfront from two different locations, I verified that the CNAMEs resolved to completely different sets of IP addresses. The first server resolved to a set of 8 IP addresses in Amazon's LAX data center (lax1.cloudfront.net), the second server resolved to 8 IP addresses in Amazon's SFO datacenter (sfo4.cloudfront.net).
I selected an object in our Cloudfront distribution and did a "wget --server-response" from each location, and then compared the results. I did this for each data center multiple times to get responses from different IP addresses in each datacenter.
The results were that the Etags were the same, regardles of which datacenter I hit, and which IP address responded from that datacenter.
I did notice that the following headers DID differ between servers
x-amz-id-2
x-amz-request-id
Age
X-Amz-Cf-Id
Via
Hope this helps,
David
[edited - removed comments on eTags based on good correction below]
2023 更新
Amazon 现在支持在 CloudFront 分配上添加/删除标头。 公告。
如何设置
在我的例子中，我想删除特定 URL 模式的 ETag。因此，在 AWS 控制台上，我转到 CloudFront 分发版，单击“行为”选项卡，然后单击“创建行为”。
在
缓存密钥和源请求部分中，您可以配置响应标头策略。该字段正下方有一个用于创建新策略的链接。在
创建响应标头策略表单中，有一个删除标头部分，您可以在其中指定所有标头你想要删除。添加ETag并保存。返回创建行为表单，在自定义选择组下选择您的新策略。如果需要，单击字段旁边的刷新按钮可刷新列表。仍然得到 304？
ETag 并不是唯一可以产生 304 的机制。在我的例子中，客户端正在发送
If-Modified-Since。您可以删除Date响应标头，但我不太喜欢这种方法。相反，我将 CloudFront 配置为忽略If-Modified-Sincerequest 标头。为此，您可以在同一
缓存密钥和源请求部分中配置源请求策略。对于
标头，选择除此之外的所有查看器标头，然后配置您希望 CloudFront 在将请求转发到之前从请求中剥离的请求标头。原点（本例中为 S3）。我添加了If-Modified-Since和If-None-Match。但是，如果您使用这种方法，则必须在行为中将
Cachepolicy设置为CachingDisabled，否则您的请求将不会始终到达源（S3），因此无法有效避免304状态。警告：如果您的源是 S3 存储桶，并且该存储桶未以到达 CloudFront 分配的自定义域命名（即：
Host）标头，则必须忽略Host标头>www.example.com）。否则，对于与您使用此源请求策略设置的行为匹配的任何请求，您都会看到指定的存储桶不存在错误。还值得一提的是，您应该考虑在 Origin 中使用正确的缓存标头。没有理由避免返回 304，因为它会加快一切速度，而且大多数客户端都会很好地处理它。如果您的客户端有些问题并且您无法控制它，我只会考虑这种方法。
2023 update
Amazon now supports adding/removing headers on a CloudFront distribution. Announcement.
How to setup
In my case, I wanted to remove the ETag for a particular URL pattern. So on AWS Console I went to my CloudFront Distribution and clicked the
Behaviorstab and clickedCreate behavior.In the
Cache key and origin requestssection, you can configure aResponse headers policy. There is a link right below the field to create a new policy.In the
Create response headers policyform, there is aRemove headerssection in which you can specify all the headers you want removed. AddETagand save it. Back to theCreate behaviorform, select your new policy under theCustomselect group. Click the refresh button alongside the field to refresh the list if needed.Still getting 304?
ETag is not the only mechanism that can yield a 304. In my case, the clients were sending
If-Modified-Since. You can remove theDateresponse header, but I don't particularly like that approach. Instead, I configured CloudFront to ignore theIf-Modified-Sincerequest header.To do so, in the same
Cache key and origin requestssection, you can configure aOrigin request policy.For
Headers, select theAll viewer headers exceptand then configure which requests headers you want CloudFront to strip from the request before forwarding it to the origin (S3 in this case). I've addedIf-Modified-SinceandIf-None-Match.However, if you use this approach, you'll have to set the
Cache policytoCachingDisabledin the Behavior, otherwise your requests will not always reach the Origin (S3), thus it won't be effective to avoid the 304 status.Warning: if your origin is a S3 bucket, you have to ignore the
Hostheader if the bucket is not named after the custom domain reaching the CloudFront distribution (i.e.:www.example.com). Otherwise, you'll see theThe specified bucket does not existerror for any request matching the Behavior you setup with this Origin request policy.It is also worth to mention that you should consider using the correct caching headers in your Origin. There are few reasons to avoid returning a 304, as it speeds up everything and most clients will handle it nicely. I'd only consider this approach if your client is somewhat broken and you can't control it.