背景：有充分的理由希望禁用某些网站资产的Last-Modified和ETag标头：以防止浏览器发送条件请求（分别使用If-Modified-Since或If-None-Match）。这很好，因为对于 URL 中具有版本号或摘要的资产，条件请求只是浪费往返时间——即当您承诺 URL 将永远提供相同的内容主体时。在这种情况下，强制浏览器在重复访问时直接转到其本地缓存通常更好。
我的问题：我想使用 S3 和 CloudFront 托管一个静态网站。它的流量相当低，而且我希望它速度快。但没有明显的方法可以阻止这些标头到达客户端 - 您无法在 S3 上禁用它们，也无法配置 CloudFront 以将其删除。
我考虑过的选项：
- 在 S3 和 CloudFront（例如 EC2）之间放置一个代理，其唯一任务就是删除这些标头
- 但对我来说，这违背了拥有静态站点的初衷；我想尽量减少移动部件
- 使用允许您剥离标头的其他 CDN（例如，可以使用 Fastly 的 VCL 配置执行此操作）
- 但我真的很喜欢 CloudFront 的零最低月消费，这对于低流量的网站来说非常便宜。
还有什么我还可以尝试吗？
答案1
...当您承诺 URL 将永远提供相同的内容主体时。在这种情况下，强制浏览器在重复访问时直接转到其本地缓存通常是更好的选择。
浏览器（或其他缓存）不会访问源，除非它认为内容已过期。对于您的情况，您可能希望发送适当的Cache-Control或Expires标头来指示最长的缓存时间。这是创建有关 URL 稳定性的承诺的唯一方法。删除ETag和Last-Modified将增加发送的数据，而不是减少。这是因为如果没有这些标头，浏览器和源将被迫刷新整个内容，而不是简单地执行轻量级刷新重新验证。
在使用 CDN 的情况下，您可能正在寻找一种允许您覆盖交付给最终用户的Cache-Control和Expires标头的方法，以指示他们应该无限期地缓存内容，即使 CDN 需要重新验证它也是如此。因此，无论您向最终客户宣传什么，如果 CDN 能够根据ETag和Last-Modified标头重新验证内容，这对您有利。