除上面的通用规则外，通常您需要指定一些规则以便于更好地缓存不同种类的内容。例如，如果登录的用户都看到的是同样的网站视图，就应该在任何地方缓存这个页面。如果登录的用户会在一段时间内看到站点中用户特定的视图，您应该让用户的浏览器缓存该数据而不应让任何中介节点缓存该视图。
Web内容缓存的位置Web内容会在整个分发路径中的许多不同的位置被缓存：
浏览器缓存：Web浏览器自身会维护一个小型缓存。典型地，浏览器使用一种策略指示缓存最重要的内容。这可能是用户相关的内容或可能会再次请求且下载代价较高。
中间缓存代理：任何在客户端和您的基础架构之间的服务器都可以按期望缓存一些内容。这些缓存可能由ISP（网络服务提供者）或者其他独立组织提供。
反向缓存：您的服务器基础架构可以为后端的服务实现自己的缓存。如果实现了缓存，那么便可以在处理请求的位置返回相应的内容而不用每次请求都使用后端服务。
上面的这些位置通常都可以根据它们自身的缓存策略和内容源的缓存策略缓存一些相应的内容。
缓存头部缓存策略依赖于两个不同的因素。所缓存的实体本身需要决定是否应该缓存可接受的内容。它可以只缓存部分可以缓存的内容，但不能缓存超过限制的内容。
缓存行为主要由缓存策略决定，而缓存策略由内容拥有者设置。这些策略主要通过特定的HTTP头部来清晰地表达。
经过几个不同HTTP协议的变化，出现了一些不同的针对缓存方面的头部，它们的复杂度各不相同。下面列出了那些你也许应该注意的：
**Expires**：尽管使用范围相当有限，但Expires头部是非常简洁明了的。通常它设置一个未来的时间，内容会在此时间过期。这时，任何对同样内容的请求都应该回到原始服务器处。这个头部或许仅仅最适合回退模式（fall back）。
**Cache-Control**：这是Expires的一个更加现代化的替换物。它已被很好的支持，且拥有更加灵活的实现。在大多数案例中，它比Expires更好，但同时设置两者的值也无妨。稍后我们将讨论您可以设置的Cache-Control的详细选项。
**ETag**：ETag用于缓存验证。源服务器可以在首次服务一个内容时为该内容提供一个独特的ETag。当一个缓存需要验证这个内容是否即将过期，他会将相应的ETag发送回服务器。源服务器或者告诉缓存内容是一致的，或者发送更新后的内容（带着新的ETag）。
Last-Modified：这个头部指明了相应的内容最后一次被修改的时间。它可能会作为保证内容新鲜度的验证策略的一部分被使用。
**Content-Length**：尽管并没有在缓存中明确涉及，Content-Length头部在设置缓存策略时很重要。某些软件如果不提前获知内容的大小以留出足够空间，则会拒绝缓存该内容。
**Vary**：缓存系统通常使用请求的主机和路径作为存储该资源的键。当判断一个请求是否是请求同样内容时，Vary头部可以被用来提醒缓存系统需要注意另一个附加头部。它通常被用来告诉缓存系统同样注意Accept-Encoding头部，以便缓存系统能够区分压缩和未压缩的内容。
Vary头部的隐语Vary头部提供给您存储同一个内容的不同版本的能力，代价是降低了缓存的容量。
在使用Accept-Encoding时，设置Vary头部允许明确区分压缩和未压缩的内容。这在服务某些不能处理压缩数据的浏览器时很重要，它可以保证基本的可用性。Vary的一个典型的值是Accept-Encoding，它只有两到三个可选的值。
一开始看上去User-Agent这样的头部可以用于区分移动浏览器和桌面浏览器，以便您的站点提供差异化的服务。但User-Agent字符串是非标准的，结果将会造成在中间缓存中保存同一内容的许多不同版本的缓存，这会导致缓存命中率的降低。Vary头部应该谨慎使用，尤其是您不具备在您控制的中间缓存中使请求标准化的能力（也许可以，比如您可以控制CDN的话）。
缓存控制标志怎样影响缓存上面我们提到了Cache-Control头部如何被用与现代缓存策略标准。能够通过这个头部设定许多不同的缓存指令，多个不同的指令通过逗号分隔。
一些您可以使用的指示内容缓存策略的Cache-Control的选项如下：
no-cache：这个指令指示所有缓存的内容在新的请求到达时必须先重新验证，再发送给客户端。这条指令实际将内容立刻标记为过期的，但允许通过验证手段重新验证以避免重新下载整个内容。
no-store：这条指令指示缓存的内容不能以任何方式被缓存。它适合在回复敏感信息时设置。