我正在为电子商务平台开发一个缓存系统，该系统将使用反向代理进行缓存。我计划通过使用正确的HTTP / 1.1标头来处理无效。也就是说，我将在第一代内容上设置一个ETag，并将该ETag值缓存在应用程序中。Cache-Control标头将指定“必须重新验证”，因此代理应在随后的带有ETag的请求上设置If-None-Match标头。应用程序将查找缓存的ETag值，如果匹配则将发送304响应，否则将生成完整的200响应。
我希望使用nginx，但我不能确定它是否支持ETags（文档表明它不支持ETags，但也许它们已经过时了？）。清漆是另一种选择，但我在这里也不满意。
哪些反向代理服务器完全支持ETag？我希望它实际上可以缓存多个版本，因此我可以执行拆分测试之类的事情而不必禁用缓存。也就是说，HTTP / 1.1指定客户端可以发送具有多个ETag值的If-None-Match，并且服务器应以匹配的ETag响应（如果有）。如果反向代理保留多个副本而不只是最后看到的值，并让服务器在每个要使用的请求上指定，那将是理想的。
Answers:
我只是签入Varnish源代码，即使它支持If-Modified-Since和If-None-Match标头，也不支持must-revalidate中Cache-Control。唯一支持的属性在Cache-Control是max-age和s-max-age。
参考文献：
bin/varnishd/cache/cache_rfc2616.c在RFC2616_Do_Cond（）中bin/varnishd/cache/cache_rfc2616.c在RFC2616_Ttl（）中include/tbl/http_headers.h如果我错了，请纠正我，我知道这是一篇旧文章-但我想为新的路人发表评论。我相信反向代理缓存对使用ETag的帮助不尽如人意。
验证缓存机制使用源服务器来验证请求中的ETag（或上次修改日期）是否仍然有效（匹配或不匹配资源etag，具体取决于所使用的标头，或是否已修改）自要求中给出的日期起）。
这意味着反向代理缓存（例如Varnish）仍会将请求传递给原始服务器。它可能会响应请求，而不是由服务器处理，但是您没有保存到原始服务器的往返行程。
浏览器可以在任何情况下缓存响应并处理304响应，因此与使用反向代理（YMMV，尤其是大规模扩展，当然取决于您的使用情况）相比，用户的私有缓存可能更适合处理此问题。想要对您的应用进行假设）。
根据规范13.3：
当缓存中有一个过时的条目要用作对客户端请求的响应时，它首先必须与原始服务器（或可能是具有新响应的中间缓存）进行检查，以查看其缓存条目是否仍然可用。我们称此为“验证”缓存条目。由于如果缓存的条目是好的，我们不需要支付重新传输完整响应的开销，并且如果缓存的条目无效，我们也不想支付额外的往返开销，因此HTTP / 1.1协议支持使用条件方法。
然后注意13.3.4：
一个HTTP / 1.1缓存代理，在接收到一个包含上次修改日期和一个或多个实体标签作为缓存验证器的条件请求后，务必不要将本地缓存的响应返回给客户端，除非该缓存的响应与所有请求中的条件标头字段。
因此，Varnish可以为您返回响应，但是您仍然可以往返于服务器。如果您可以使用APC或内存缓存之类的应用程序缓存，那么对您来说还是值得的。但是，验证缓存通常比节省服务器资源更好地节省带宽。
验证缓存最好留给客户端（浏览器或api代码）。
使用Expiration模型进行缓存是真正实现反向代理缓存的地方。这样，您就可以完全跳过原始服务器。使用Expires，Cache-Control，Date等，是最好的（再次，IMO）的反向代理缓存作为缓存可以返回的响应机制，假设它不是陈旧的，不会去访问原始服务器。
到目前为止，我相信仍然没有完全支持此HTTP规范的代理。因此，大约一年前，我决定使用Node.js和MongoDb编写自己的代码。