我正在开发一个电子商务平台的caching系统，它将使用反向代理进行caching。 我打算通过使用正确的HTTP / 1.1头来处理失效。 也就是说，我将在第一代内容上设置一个ETag，并在应用程序中cachingETag值。 Cache-Control头将指定“must-revalidate”，所以代理应该在随后的ETag请求上设置If-None-Match头。 应用程序将查找caching的ETag值，如果匹配，则会发送一个304响应，否则它将生成一个完整的200响应。
我希望使用nginx，但我不能肯定它支持ETags（文档指出它不，但也许他们已经过时？）。 清漆是另一种select，但我在这里也不积极。
哪些逆向代理服务器对ETag有完整的支持？ 我希望它实际上caching多个版本，所以我可以做分裂testing，而不必禁用caching。 也就是说，HTTP / 1.1指定客户端可以发送带有多个ETag值的If-None-Match，并且服务器应该响应与哪个ETag匹配（如果有的话）。 如果反向代理保存了多个副本而不是最后一次看到的值，并让服务器在每个要使用的请求上指定，那将是理想的。
我刚刚检查了Varnish源代码，即使它支持If-Modified-Since和If-None-Match头，它也不支持Cache-Control must-revalidate 。 Cache-Control中唯一支持的属性是max-age和s-max-age 。
参考文献：
bin/varnishd/cache/cache_rfc2616.c in RFC2616_Do_Cond（） bin/varnishd/cache/cache_rfc2616.c in RFC2616_Ttl （） include/tbl/http_headers.h nginx需要第三方模块来支持ETag。 其中有两个 。
纠正我，如果我错了，我知道这是一个旧的职位 – 但我想评论新的路人。 我相信一个反向代理caching不会像使用ETags时那样有用。
validationcaching机制使用原始服务器validation请求中的ETag（或上次修改的date）是否仍然有效（匹配或不匹配资源etag，具体取决于使用哪个头，还是未被修改自请求date起）。
这意味着反向代理caching（如Varnish）仍将该请求传递给原始服务器。 它可以响应请求，而不是让服务器处理它，但是你没有保存到源服务器的往返。
浏览器可以在任何情况下caching响应和处理304响应，所以用户的私有caching可能比使用反向代理（YMMV，尤其是在规模上，当然取决于你的使用情况）更适合处理这个问题。想要对你的应用程序进行假设）。
从规格13.3 ：
当caching有一个陈旧的条目，它想用来作为客户端的请求的响应，它首先必须检查源服务器（或可能是一个新的响应的中间caching），看它的caching条目是否仍然可用。 我们称之为“validation”caching条目。 由于如果caching条目良好，我们不想支付重传全部响应的开销，并且如果caching条目无效，我们不想支付额外的往返开销，HTTP / 1.1协议支持使用条件方法。
然后注释13.3.4 ：
HTTP / 1.1caching代理在接收到包含Last-Modifieddate和一个或多个实体标签作为cachingvalidation器的条件请求时，绝不能将本地caching的响应返回给客户端，除非caching的响应与所有请求中的条件标头字段。
所以，Varnish可以为你返回一个响应，但你仍然可以往返服务器。 如果您可以使用APC或memcache等应用程序caching，那么这对您来说可能还是值得的。 然而，validationcaching通常比节省服务器资源更好地节省带宽。
validationcaching最好留给客户端（浏览器或API代码）。
使用过期模型进行caching是反向代理caching真正发光的地方。 这可以让你跳过原点服务器。 使用Expires ， Cache-Control ， Date等是反向代理caching的最好的（又是IMO）机制，因为caching可以返回响应，假设它没有失效，甚至没有碰到原始服务器。
你可以看看Apache TrafficServer ，这似乎有你所需要的 。
到目前为止，我相信还没有代理完全支持这个HTTP规范。 所以，大约一年前，我决定用Node.js和MongoDb编写自己的代码。