Hey Maxim,
> That's up to a configuration.
You're right... It seems like a waste of disk space to me, but nginx
can be forced to do that.
This still leaves us with only 200 and 206.
> Which problem? You are trying to convince me that that
> conditional requests shouldn't be used to revalidate responses
> with non-200 status code because it may not work with some
> upstream servers. Sure, this can happen. Moreover, it can happen
> with responses with 200 status code, too.
No, I'm saying that it cannot work.
Maybe I shouldn't have tried to explain the reasoning behind
fd283aa92e04, because it looks that it just added confusion, so let's
start again.
1. client #1 requests "/logo.png" from website behind nginx,
2. nginx doesn't have "/logo.png" in cache, so it sends request upstream,
3. upstream server rate-limits nginx and replies with 503:
HTTP/1.1 503 Service Temporarily Unavailable
Last-Modified: Mon, 24 Nov 2014 22:00:00 GMT
4. 503 gets force-cached at nginx (due to configuration),
5. client #2 requests "/logo.png" from website behind nginx,
6. nginx has "/logo.png" in cache, but it's expired, so it tries to
revalidate it:
GET /logo.png HTTP/1.1
If-Modified-Since: Mon, 24 Nov 2014 22:00:00 GMT
7. upstream replies with 304, accidentally revalidating 503:
HTTP/1.1 304 Not Modified
even though, the 304 is generated from:
HTTP/1.1 200 OK
Last-Modified: Mon, 10 Nov 2014 00:00:00 GMT
not from the rate-limiting.
This scenario describes perfectly behaving upstream server, the only
issue here is that nginx tries to revalidate response that cannot be
revalidated and applies 304 Not Modified response to it.
> Two trivial solutions include:
>> - fix an upstream server;
There is no issue with the upstream server, only with nginx
revalidating non-200 status codes.
> - disable use of conditional requests, it's off by default.
So you're saying that just because it's off by default, it's fine for
it to be broken?
Best regards,
Piotr Sikora