Old thread: Cache for non-cookie users and fresh for cookie users

[Max]

11 февраля 2012, 18:49 от Quintin Par <quintinpar at gmail.com>:
> Sorry for being late to respond.
> 
> There is so much that’s being discussed that does not reflect in the wiki –
> people like me think the wiki is the canonical document.
> 
> I like max’s approach but need to cache only in the next GET. Mostly
> because some XMLHTTP post request under the same location directive will
> invalidate and recache in this context. But that might not be a candidate
> to recache. E.g. storing page performance counters after a page’s been
> loaded.
> 
> Can that be done with your approach? Just to invalidate?

No. AFAIK, there is no way to cause forced cache invalidation that
would remove specific cache entries without using 3rd party modules,
such as Piotr Sikora's excellent ngx_cache_purge. You should definitely
include that module in your next scheduled nginx upgrade.

In the meantime, you could use something like this to force the
cache contents for "/furniture/desks/" to be refreshed by
sending a request for "/refresh_cache/furniture/desks":

# Responses for "/blog" and "/blog?action=edit" requests
# are cached under the SAME key
proxy_cache_key $scheme$host$uri;

location ~ ^/refresh_cache/(.*)$ {

    # Change the key to match the existing key
    # of the cache entry you want to refresh
    proxy_cache_key $scheme$host/$1;

    proxy_cache_bypass "Never check the cache!";

    # Pass the request directly to the backend
    # and store the response in the cache
    proxy_pass $scheme://backend/$1;
}

This is just meant to demonstrate the general approach.

Max