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

Max nginxyz at mail.ru
Fri Feb 10 15:41:17 UTC 2012


10 февраля 2012, 19:06 от António P. P. Almeida <appa at perusio.net>:
> On 10 Fev 2012 14h45 WET, nginxyz at mail.ru wrote:
> 
> > 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.
> >
> 
> Why all this? The default behavior is for POSTed requests never to be
> cached.

That's exactly why all that is necessary - to force each POST method request
response to be cached, and to refresh the cache immediately.

Let's say a blog entry is updated (through a POST method request to
"blog?edit=action") - then all those clients who are reading the blog
(through GET method requests) will be getting the old, stale version
of "/blog" from the cache until the cache validity expires. With my
approach, on the other hand, the cache is refreshed immediately
on every POST method request (because GET method requests
for "/blog" and POST method requests for "/blog?action=edit" are
cached under the same key), so all clients get the latest version
without the cache validity having to be reduced.

Max


More information about the nginx mailing list