我似乎无法find足够的文档。 我有一个应用程序生成一些dynamic的响应，但仍然可以受益于Last-Modified头 – 所以我发送它。
但是，启用if_modified_since （设置为before ，根据http://nginx.org/en/docs/http/ngx_http_core_module.html#if_modified_since ）似乎对非静态资源没有任何影响。 例如，PHP，Python应用程序。
这是因为Nginx不只是看我的回应Last-Modified头？ 因为我可以看到他们似乎设置正确，如下所示：
> GET /3.0/view.json?id=2 HTTP/1.1 > Host: xxxxxxxxxxxxx > Accept: */* > If-Modified-Since: Sat, 02 May 2015 19:43:02 GMT > < HTTP/1.1 200 OK * Server nginx/1.4.7 is not blacklisted < Server: nginx/1.4.7 < Date: Fri, 01 May 2015 19:56:05 GMT < Content-Type: application/json; charset=utf-8 < Transfer-Encoding: chunked < Connection: keep-alive < Vary: Accept-Encoding < Last-Modified: Fri, 01 May 2015 19:56:05 GMT
还是有更大的东西，我俯瞰？ 只是好奇，如何if_modified_since实施，相比，我设定我的期望。 我认为它只是看响应头，并根据需要覆盖状态。 我错了吗？
在您的应用程序中发送Last-Modified标题回复是一个开始，但似乎你不处理If-Modified-Since正确的传入的请求，因为你的应用程序应该回复304 Not Modified而不是200 OK 。 更改nginx上的指令只会影响nginx直接提供的请求，即静态资源，除非您将其configuration为反向代理caching。 在这种情况下，您可能会针对此标头值提供过时的回复，因为内容将被caching一段时间而不会触碰您的应用。 启用<X>_cache_revalidate on将会使用If-Modified-Since标头在nginx的caching和应用程序过期之后，对caching内容进行重新validation（其中<X> = proxy / fastcgi / scgi / uwsgi）
既然你没有在Nginx中提到你的cachingconfiguration，我会假设你没有设置caching，这将解释为什么你的If-Modified-Since头对dynamic响应没有影响。
对于静态资源，Nginx有一个非常简单的方法来确定如何处理If-Modified-Since ：它将字段中的时间与上次修改文件的时间进行比较。 那里没问题。
当你希望Nginx和dynamic生成的响应一样时， 除非你打开caching ， 否则没有什么可以比较的。 默认情况下，Nginx不记得它所服务的响应。 当您打开caching时，Nginx有一种方法可以将传入的请求与之前给出的响应进行比较，因此可以使用If-Modified-Since 。
我发现这篇文章对于学习设置Nginxcaching的更精细的细节非常有用。