proxy_cache incorrectly returning 304 Not Modified

[Maxim Dounin]

Hello!

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_(http://www.pingdom.com/)
> Host: loco2.com
> 
> 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 
problem.

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
http://nginx.org/