理想的HTTPcaching控制标题为不同types的资源

我想find一个最小的头文件集，可以处理“全部”caching和浏览器（也可以使用HTTPS ！）

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

（1）永久可caching（公开/平等的所有用户）

^{例如：0A470E87CC58EE133616F402B5DDFE1C.cache.html（ 由GWT自动生成 ）}

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

• 即使使用HTTPS，他们也应该尽可能地caching（所以我认为我应该设置Cache-Control: public ，特别是Firefox）。

• 如果内容发生了变化，他们不应该要求客户端往返于服务器进行validation。

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

^{示例：index.html，mymodule.nocache.js}

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

• 他们可以被caching，但可能需要往返每次重新validation。

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

^{例如：JSON响应}

• 在任何情况下，永远不应该将这些资源caching到磁盘。 （除了可能我会有一些具体的请求，可以被caching。）

---

我有一个大概的想法，我可能会使用每个types的头，但总是有我可能会丢失的东西。

Answer 1

我可能会使用这些设置：

1. Cache-Control: max-age=31556926 – 表示可以被任何cachingcaching。 caching表示被认为是新鲜的1年：
   

   为了将响应标记为“永不过期”，源服务器从发送响应的时间起大约一年发送一个过期date。 HTTP / 1.1服务器不应该在将来发送超过一年的过期date。

2. Cache-Control: no-cache – 表示被允许被任何cachingcaching。 但caching必须在释放caching副本之前将请求提交到原始服务器进行validation。
3. Cache-Control: no-store – caching在任何情况下都不能caching表示。

请参阅Mark Nottingham的caching教程以获取更多信息。

Answer 2

案例一和案例二是相同的情况。 您应该设置Cache-Control: public ，然后生成一个包含网站的内部版本号的URL，这样您就拥有了不可变的资源，可以永远持续下去。 您还希望在将来一年或更长时间设置Expires标题，以便客户不需要发出新鲜度检查。

对于案例3，您可以通过以下所有方式获得最大的灵活性：

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