使用缓存标头，我可以让客户端在一段时间内不在线检查更新，和/或每次检查etags。我不知道的是我是否可以同时使用：首先使用离线版本，但同时在后台，检查更新。如果有新版本，则会在下次打开页面时使用它。
对于完全静态的页面，除非用户自己更改它，这比每次阻止检查etag更有效。
我想到的一个解决方法是使用Javascript：set headers来无限期地缓存页面并让一些Javascript使用If-Modified-Since或其他东西发出请求，然后可以动态地更改页面。这个问题的一大问题是它无法使现有缓存无效，因此它必须在理论上永远保持动态更新页面。我也更喜欢保持纯HTTP（或HTML，如果有一些标签可以做到这一点），但我在网上找不到任何相关的点击。
一个相关的问题提到＆＃34;两个缓存规则＆＃34 ;:永远不会缓存HTML并永远缓存其他所有内容。为了清楚起见，我的意思是缓存HTML。我正在构建的东西的全部目的是在非常慢的连接上实现非常快（高延迟，低吞吐量，如EDGE）。保存的每次往返都是第二次或第二次加载时间。
更新：阅读更多缓存资源，似乎Vary: Cookie标题可能在我的情况下起作用。我想知道是否有一个更通用的解决方案，而且我并没有真正深入了解vary-header，所以我还不知道是否有效。
答案 0 :(得分：1)
有一个缓存控制扩展stale-while-revalidate，可以准确描述您想要的内容。
当出现在HTTP响应中时，sale-while-revalidate Cache- 控制扩展指示缓存可以为响应提供服务 在它变得陈旧之后它出现，直到指定的数字 几秒钟。
如果缓存的响应因此存在而过时 扩展，缓存应该尝试重新验证它仍然 提供陈旧的回应（即没有阻止）。
cache-control: max-age=60,stale-while-revalidate=86400
当浏览器首先请求页面时，它会将结果缓存60秒。在60秒期间，从缓存中回答请求而不联系源服务器。在接下来的86400s中，内容将从缓存中提供，并同时从源服务器获取。仅当两个句点60s + 86400s都过期时，缓存不会提供缓存内容，而是等待源服务器获取新数据。
此解决方案只有一个缺点。我无法找到当前支持此缓存控制扩展的任何浏览器或中间缓存。
另一种解决方案是使用Service workers及其功能来对请求进行自定义响应。与Cache API结合使用即可提供所需的功能。
问题是此解决方案仅适用于浏览器（不是中间缓存或其他http服务），甚至并非所有浏览器都支持服务工作者和缓存API。