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

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