Hey Maxim,

> And what's wrong with it?
> I don't see why this should be status-specific.

Because, according to the RFC, 304 Not Modified can be only emitted
for 200 OK responses, so we know that revalidation of other status
codes cannot happen, at least not when talking with well-behaving
server, so sending conditional requests for such cached responses is
pointless.

Maybe I should elaborate a bit more on the problem I'm trying to
workaround, which is also the underlying reason for the fix I made in
fd283aa92e04.

Prior to that commit, when nginx cached 404 Not Found response without
Last-Modified header, i.e. with such minimal headers:

HTTP/1.1 404 Not Found
Date: Wed, 19 Nov 2014 21:12:47 GMT

it would always try to revalidate it with bogus If-Modified-Since header:

GET /notfound HTTP/1.1
Host: www.example.com
If-Modified-Since: Thu, 01 Jan 1970 00:00:00 GMT

for which upstream server would usually respond with full 404 Not
Found response (not 304 Not Modified), unless the file appeared on the
upstream server (and would have resulted in 200 OK for unconditional
requests), then it would respond with 304 Not Modified (thanks to the
broken If-Modified-Since test on their side), revalidating 404 Not
Found based on the 200 OK response.

The problem mostly disappeared after fd283aa92e04, but it can still
happen, e.g. when cached 404 Not Found response with Last-Modified
header will be revalidated (and hence cached forever) by 304 Not
Modified sent instead of 200 OK response with Last-Modified header
older than the one in cached response.

Hopefully that explains the problem enough... Let me know if you still
have any doubt as to why it is important to change the current
behavior to send conditional requests only for cached 200 OK
responses.

Best regards,
Piotr Sikora

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