首页 文章

适用于不同类型资源的理想HTTP缓存控制标头

提问于
浏览 次
78

我想找到一个最小的标头集，它可以与"all"缓存和浏览器一起使用（当使用 HTTPS 时！）

在我的网站上，我将有三种资源：

（1）永远可缓存（所有用户的公共/相等）

示例：0A470E87CC58EE133616F402B5DDFE1C.cache.html（由GWT自动生成）

  • 这些文件在更改内容时会自动分配新名称（基于MD5） .

  • 他们应该尽可能地缓存，即使使用HTTPS（所以我假设，我应该设置 Cache-Control: public ，特别是对于Firefox？）

  • 如果内容发生变化，他们不应要求客户端往返服务器进行验证 .

（2）偶尔更改（所有用户公开/平等）

示例：index.html，mymodule.nocache.js

  • 当部署新版本的站点时，这些文件会更改其内容而不更改URL .

  • 它们可以被缓存，但可能需要每次都要重新验证往返 .

（3）每个请求的个人（私人/用户特定）

示例：JSON响应

  • 在任何情况下都不应将这些资源缓存到未加密的磁盘 . （除非我有一些可以缓存的特定请求 . ）

我有一个大概的想法，我可能会为每种类型使用哪些 Headers ，但总会有一些我可能会遗漏的东西 .

http caching https http-headers

2 回答

  • 86

    我可能会使用这些设置：

    • Cache-Control: max-age=31556926 - 任何缓存都可以缓存表示 . 缓存的表示将被视为新鲜1年：

    要将响应标记为“永不过期”，原始服务器会在发送响应大约一年后发送过期日期 . HTTP / 1.1服务器不应该在未来发送超过一年的过期日期 .

    • Cache-Control: no-cache - 允许任何缓存缓存表示 . 但是缓存必须在发布缓存副本之前将请求提交给源服务器进行验证 .

    • Cache-Control: no-store - 缓存不得在任何条件下缓存表示 .

    有关详细信息，请参见Mark Nottingham’s Caching Tutorial .

    回复于
  • -2

    案例一和二实际上是相同的情况 . 您应该设置 Cache-Control: public ，然后生成一个URL，其中包含站点的内部版本号/版本，以便您拥有可能永久持续的不可变资源 . 您还希望将来设置 Expires 标头一年或更长时间，以便客户端不需要发出新鲜度检查 .

    对于案例3，您可以获得以下所有灵活性：

    "Cache-Control", "no-cache, must-revalidate"
"Expires", 0
"Pragma", "no-cache"
    回复于

相关问题