问题描述
考虑到服务器使用以下标头进行响应:
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 并确认它尊重这些标头,并且所有请求都指向相同的缓存键
- 预计每天会有多个请求发送到您的源服务器