使用 Cloudfront 时，如何设置相对于当前日期的 Expires Header？

Posted 2023-03-27

【中文标题】使用 Cloudfront 时，如何设置相对于当前日期的 Expires Header？

【英文标题】：When using Cloudfront, how can one set the Expires Header relative to the current Date?

【发布时间】：2011-06-13 05:24:02

【问题描述】：

我们正在开发一个大型网站，我们所有的图片和资源都在 Amazon S3 中。我们还使用 Cloudfront 在全球范围内分发我们的内容。我们想要做的是告诉客户端 Web 浏览器缓存我们的文件，因为当我们更改它们时，我们也会更改 URL（Cloudfront 不会在其他地方反映 24 小时的更改）。

我们目前正在使用 ETag，但这不是最佳选择，因为客户端仍然需要执行请求以检查资源是否已更改。

一个解决方案是 Expires 标头，但我们没有找到一种方法来设置它相对于当前日期，就像在 S3 的 Apache 配置中可能的那样，我们不能定期更新所有内容，因为它几乎是。因此，我们需要一个配置选项，将 Expires 标头设置为相对于所有内容的当前日期的日期。

另一种解决方案是将 Cache-Control: max-age 设置为某个值。这行得通吗？它被主要浏览器接受吗？我会用这个破坏一些缓存算法吗？为什么 YSlow 建议设置 Expires 标头而不设置 Cache-Control: max-age？

还有其他推荐吗？我们正在压缩 CSS 和 JS，在合理的地方使用 Sprites，在可能的地方设置 Expires 标头和 ETag，并且很快将使用 Yahoo Compression Tool 和 gzipping Output 压缩我们的图像。

【参考方案1】：

我们对自己做了一些研究。似乎 Cache-Control 标头确实有助于告诉 Cloudfront 或代理设置有效的 Expires 标头，但只是有时...

我们目前正在编写一个 Cron 作业来定期更新 S3 中的所有标头，因为这是肯定有效的一件事。好像没有别的办法了。如果有，我会及时通知你。

【讨论】：

嗨，Paul，我也遇到了同样的问题，您有没有更好的解决方案？

不，AFAIK 没有更好的解决方案。

@PaulWeber 你能分享一下你做了什么我也需要做类似的事情

抱歉，我现在在另一家公司工作，无法再访问该脚本。但是，如果您有文件列表，使用 s3tools.org/usage 应该很容易。

【参考方案2】：

为什么需要相对于当前日期的缓存持续时间？

你说：

“当我们更改它们时，我们也会更改 URL”

这对我来说意味着您的资源永远不会改变。为什么不将 Expires Header 设置为遥远的未来日期（例如 2020 年 1 月 1 日）？

【讨论】：

好主意。我不知道为什么我们放弃了这个解决方案，但我认为这是因为如果过期日期太远了，一些浏览器或代理会忽略它。我们目前让我们的内容在 1 年内到期，这是可行的，但我们可能会尝试增加这一期限。

RFC-2616 第 14.21 节说“要将响应标记为‘永不过期’，源服务器会在响应发送后大约一年发送一个过期日期。HTTP/1.1 服务器不应该发送到期日期超过未来一年。”这在实践中是否真的是一个问题，我不知道。

缓存现在终于要过期了！ :')