缓存资源一段时间，然后使用 HTTP 缓存对其进行验证

如何解决缓存资源一段时间，然后使用 HTTP 缓存对其进行验证

考虑到服务器使用以下标头进行响应：

Cache-Control: public
Expires: <EXPIRATION DATE>
ETag: <HASH VALUE>

如果底层资源没有实际更新，那么 <EXPIRATION DATE> 和 <HASH VALUE> 都不会改变。

我对以下内容的期望是正确的：

• 所有中间代理服务器（包括 CDN）都会认为该资源是公开的并且可以安全缓存。

• 所有中间代理服务器（包括 CDN）以及浏览器都将认为此资源是新鲜的，直到 <EXPIRATION DATE> 并将其从缓存中返回，而无需访问网络。然而，在<EXPIRATION DATE>之后，他们都会对每个请求使用 HTTP 验证机制来检查资源是否过时。

因此，如果资源在 <EXPIRATION DATE> 之后更新，我可以放心地期望所有客户端将在下一个请求中收到资源的新版本（因为 HTTP 验证将因 ETag 的更改而失败）？

我对标准的角度 (RFC) 和现实生活的角度（例如已知的浏览器和代理怪癖）都很感兴趣。

---

我希望我的资源是新鲜的，例如从文件在服务器上实际更新并始终从缓存返回的一天后。但是，一天后，我希望所有客户端仅在文件实际更改时（使用 HTTP 验证机制）才能收到新副本。

解决方法

正如Kevin's comment所说：

就标准而言，您的分析是正确的

在不了解您的工程要求的情况下，很难回答“已知的浏览器和代理怪癖”。听起来您可能正在提供静态内容； consider services like S3 和 CloudFront。

对于此设计，来自您的期望：

浏览器会认为这个资源是新鲜的，直到 并且会在不访问网络的情况下从缓存中返回它

当资源被直接引用时，大多数浏览器仍然会访问网络，即使它在它们的缓存中仍然是新鲜的。这应该是一个有条件的请求，但它仍然是网络流量。（immutable 可能会有所帮助。）

任何缓存都可能驱逐资源；对于one CDN：

如果不经常请求边缘站点中的文件，CloudFront 可能会驱逐该文件

如果您的目的是减少源服务器上的负载，这是一个很好的策略。您正确使用了 Expires、Cache-Control: public 和 ETag，假设您还正确处理了条件请求。在实践中，您应该：

• 为浏览器在 24 小时内发出多个请求做好准备
• 准备好调整您的 CDN 并确认它尊重这些标头，并且所有请求都指向相同的缓存键
• 预计每天会有多个请求发送到您的源服务器