Hello!

On Sun, Sep 11, 2016 at 06:56:17AM -0400, jchannon wrote:

> I have nginx and its cache working as expected apart from one minor issue.
> When a request is made for the first time it hits the origin server, returns
> a 200 and nginx caches that response. If I make another request I can see
> from the X-Cache-Status header that the cache has been hit. When I wait a
> while knowing the cache will have expired I can see nginx hit my origin
> server doing a conditional GET because I have proxy_cache_revalidate on;
> defined.
>
> When I check if the resource has changed in my app on the origin server I
> see it hasn't and return a 304 with a new Expires header. Some may argue why
> are you returning a new Expires header if the origin server says nothing has
> changed and you are returning 304. The answer is, the HTTP RFC says that
> this can be done https://tools.ietf.org/html/rfc7234#section-4.3.4
>
> One thing I have noticed, no matter what headers are I add or modify, when
> the origin server returns 304 nginx will give a response with the first set
> of response headers it saw for that resource.

Conditional revalidation as available with
"proxy_cache_revalidate on" doesn't try to merge any new/updated
headers to the response stored. This is by design - merging and
updating headers will be just too costly.

This is normally not an issue as you can (and should) use
"Cache-Control: max-age=..." instead of Expires, and with max-age
you don't need to update anything in the response.

If you can't afford this behaviour for some reason, the only
solution is to avoid using proxy_cache_revalidate.

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

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