Hello!

On Fri, Jan 10, 2014 at 12:18:18PM +0000, Jon Leighton wrote:

> 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.

It looks like your Pingdom reports are a bit confusing, and most
likely there is a body in the response, but Pingdom doesn't show it
because it's gzipped.

You may try testing with telnet / curl to see what actually goes
on.

> 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.

The "gzip off" isn't relevant, as it won't try to compress
anything with Content-Encoding already set anyway.

Note though that nginx doesn't understand "Vary: Accept-Encoding",
and will return cached response regardless of client's
Accept-Encoding. To make sure gzipped responses aren't sent to
clients without gzip support you should either disable caching of
such responses, or switch off gzip of your backend (e.g., with
"proxy_set_header Accept-Encoding '';"), or switch on gunzip in
nginx (http://nginx.org/r/gunzip).

Please also see here for some debugging hints:

http://wiki.nginx.org/Debugging

--
Maxim Dounin
http://nginx.org/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx