proxy_cache incorrectly returning 304 Not Modified

Maxim Dounin mdounin at
Thu Jan 9 14:46:50 UTC 2014


On Wed, Jan 08, 2014 at 02:57:18PM +0000, Jon Leighton wrote:

> Hi there,
> I work on a site which has nginx in front of a Rails application, and we
> use proxy_cache.
> For the home page, our application returns a "max-age=600, public"
> Cache-Control header, and we have nginx configured to cache the response
> using proxy_cache.
> This generally works fine, but last night nginx started to respond with
> 304 Not Modified to requests that *didn't* include any caching headers
> (If-Modified-Since or ETag). Our Pingdom alerts showed this issue, and
> here is the request/response captured:
> GET / HTTP/1.0
> User-Agent: Pingdom.com_bot_version_1.4_(
> Host:
> 304 Not Modified
> Cache-Control: max-age=600, public
> Date: Tue, 07 Jan 2014 22:59:32 GMT
> ETag: "900e1f11422519337c9ed25fad299ce0"
> Server: nginx/1.4.4
> Status: 304 Not Modified
> Strict-Transport-Security: max-age=31536000
> X-Cache-Status: HIT
> X-Content-Type-Options: nosniff
> X-Frame-Options: SAMEORIGIN
> X-Request-Id: c7ee78ab-df49-4467-bced-753b2cc622ab
> X-UA-Compatible: chrome=1
> X-XSS-Protection: 1; mode=block
> Connection: Close
> Does this look like a bug? Or could it be a configuration issue? I can't
> think of any reason why this should be the correct thing for the proxy
> cache to do.

This easily can be a result of a misconfiguration (e.g., 
proxy_set_header used incorrectly) and/or backend 

Additionally, response headers looks very suspicious.  There 
shouldn't be "Status: 304 Not Modified" in nginx responses, and 
"Connection: Close" capitalization doesn't match what nginx uses.  
Unless it's something introduced by Pingdom interface, this may 
indicate that it's checking something which isn't nginx.

Maxim Dounin

More information about the nginx mailing list