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

[Max]

10 февраля 2012, 12:35 от Quintin Par <quintinpar at gmail.com>:
> On Thu, Feb 9, 2012 at 2:19 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> > On Thu, Feb 09, 2012 at 12:34:33PM +0530, Quintin Par wrote:
> > > Picking up an old thread for caching
> > >
> > >
> >
> http://nginx.2469901.n2.nabble.com/Help-cache-or-not-by-cookie-td3124462.html
> > >
> > > Igor talks about caching by
> > >
> > > “No, currently the single way is:
> > >
> > > 1) add the cookie in proxy_cache_key
> > >
> > >    proxy_cache_key  "http://cacheserver$request_uri $cookie_name";
> > >
> > > 2) add "X-Accel-Expires: 0" in response with the cookie.”
> > >
> > > But from my understanding of “*X-Accel-Expires” *it expires the cache in
> > > the cache repository as given below
> > >
> > > “Sets when to expire the file in the internal Nginx cache, if one is
> > used.”
> > >
> > > Does this not mean that when I set cookie and pass “X-Accel-Expires: 0”
> > it
> > > expires the cache for the non logged in user too, for that cache key? A
> > new
> > > cache entry will then have to be created, right?
> >
> > No.  X-Accel-Expires will prevent the particular response from
> > being cached, but won't delete existing cache entry.
> >
> 
> So what should I do to delete a particular cache entry?

If you really want to avoid nginx_ngx_cache_purge at all costs,
you'll have to use something like this to force every POST
method request to refresh the cache:

proxy_cache zone;

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

# Turn caching on for POST method request responses as well
proxy_cache_methods GET HEAD POST;

location / {
    recursive_error_pages on;
    error_page 409 = @post_and_refresh_cache;

    # Redirect POST method requests to @post_and_refresh_cache  
    if ($request_method = POST) { return 409; }

    # Process GET and HEAD method requests by first checking
    # for a match in the cache, and if that fails, by passing
    # the request to the backend
    proxy_pass $scheme://backend;
}

location @post_and_refresh_cache {

    proxy_cache_bypass "Never check the cache!";

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

This generic approach is based on the assumptions that the
content on the backend is posted/modified through the same
frontend that is proxying and caching it, and that you know
how to prevent session-specific information from being leaked
through the cache.

You've been going on about this for two days now, but you still
haven't managed to explain HOW you check whether the
content has changed. It's obvious you do know the content
has changed, but without sharing the details on how and
where the content on the backend is updated, you can't
expect a more specific solution.

Max