proxy_cache incorrectly returning 304 Not Modified

[Jon Leighton]

Hello Maxim,

Thanks for your reply.
>> 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.

Thank you. I reviewed my configuration and made some tweaks, but I'm
still having trouble. Actually I haven't seen the 304 Not Modified
again, but now I am getting a blank response body for the cached page ("/").

For example:

GET / HTTP/1.0
User-Agent: Pingdom.com_bot_version_1.4_(http://www.pingdom.com/)
Host: loco2.com

200 OK
Cache-Control: max-age=600, public
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Fri, 10 Jan 2014 11:49:44 GMT
ETag: "8a8ca149d65dd1343c60366876821659"
Server: nginx/1.4.4
Status: 200 OK
Strict-Transport-Security: max-age=31536000
Vary: Accept-Encoding
X-Cache-Status: HIT
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Request-Id: 0d85f7a2-cdbf-4288-a62d-05628abefdba
X-UA-Compatible: chrome=1
X-XSS-Protection: 1; mode=block
Connection: Close

[empty response]

Do you know of any reasons why the response might be blank? I copied the
cache file so I could review it, and I checked that the X-Request-Id
matches so it's definitely the same entry. The cache file *does* contain
the response body - in gzip form. I am using "gzip off" for this
location block, so I don't think nginx is interfering there. I'm at a
complete loss about why this is happening, any ideas you have would be
much appreciated.

Thanks,
Jon