# Old thread: Cache for non-cookie users and fresh for cookie users **URL:** \ **Category:** NGINX\ **Created:** [February 9, 2012, 8:05am UTC](https://www.ruby-forum.com/t/old-thread-cache-for-non-cookie-users-and-fresh-for-cookie-users/216607 "2012-02-09T08:05:23Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![dubstep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@dubstep](https://www.ruby-forum.com/u/dubstep)\ **Post date:** [February 9, 2012, 8:05am UTC](https://www.ruby-forum.com/t/old-thread-cache-for-non-cookie-users-and-fresh-for-cookie-users/216607/1 "2012-02-09T08:05:23Z")
Picking up an old thread for caching [http://nginx.2469901.n2.nabble.com/Help-cache-or-not-by-cookie-td3124462.html](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 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? Should I go with “Cache-Control: max-age=0” approach? ---
**Author:** ![Quintin\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/13edae/32.png) [@Quintin\_P](https://www.ruby-forum.com/u/Quintin_P)\ **Post date:** [February 9, 2012, 9:50am UTC](https://www.ruby-forum.com/t/old-thread-cache-for-non-cookie-users-and-fresh-for-cookie-users/216607/2 "2012-02-09T09:50:11Z")
Hello! On Thu, Feb 09, 2012 at 12:34:33PM +0530, Quintin P. wrote: > proxy\_cache\_key “http://cacheserver$request\_uri $cookie\_name”; > 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. > Should I go with “Cache-Control: max-age=0” approach? The only difference between “X-Accel-Expires: 0” and “Cache-Contro: max-age=0” is that the former won’t be passed to client. As for the use-case in general (i.e. only use cache for users without cookie), in recent versions it is enough to do ``` proxy_cache_bypass $cookie_name; proxy_no_cache $cookie_name; ``` I.e.: don’t respond from cache to users with cookie (proxy\_cache\_bypass), don’t store to cache responses for users with cookie (proxy\_no\_cache). Moreover, responses with Set-Cookie won’t be cached by default, too. So basically just placing the above into config is enough, no further changes to a backend code required. Maxim D. ---
**Author:** ![Quintin\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/13edae/32.png) [@Quintin\_P](https://www.ruby-forum.com/u/Quintin_P)\ **Post date:** [February 10, 2012, 9:35am UTC](https://www.ruby-forum.com/t/old-thread-cache-for-non-cookie-users-and-fresh-for-cookie-users/216607/3 "2012-02-10T09:35:50Z")
On Thu, Feb 9, 2012 at 2:19 PM, Maxim D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > > being cached, but won’t delete existing cache entry. So what should I do to delete a particular cache entry? ---
**Author:** ![Quintin\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/13edae/32.png) [@Quintin\_P](https://www.ruby-forum.com/u/Quintin_P)\ **Post date:** [February 10, 2012, 9:57am UTC](https://www.ruby-forum.com/t/old-thread-cache-for-non-cookie-users-and-fresh-for-cookie-users/216607/4 "2012-02-10T09:57:29Z")
Hi, > So what should I do to delete a particular cache entry? Valentin already pointed you to the solution 2 days ago: > **[FRiCKLE Labs / nginx / ngx\_cache\_purge](http://labs.frickle.com/nginx_ngx_cache_purge/)** Best regards, Piotr S. \< [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) \> ---
**Author:** ![Quintin\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/13edae/32.png) [@Quintin\_P](https://www.ruby-forum.com/u/Quintin_P)\ **Post date:** [February 10, 2012, 3:37pm UTC](https://www.ruby-forum.com/t/old-thread-cache-for-non-cookie-users-and-fresh-for-cookie-users/216607/5 "2012-02-10T15:37:24Z")
On 10 Fev 2012 14h16 WET, removed\_email\_address@domain.invalid wrote: Replying to myself I just remembered that having an embedded variable holding the value of fastcgi\_cache\_key/proxy\_cache\_key would be awesome. Since that way using, for example, the embedded Lua module we could easily manage the cache from within Nginx without having to do additional HTTP requests. The Nginx cache is simple: just a bunch of files. So IMHO the cache purging should be as simple as possible and not having to issue additional requests for purging. I guess this is a feature request 🙂 Thx, — appa ---
**Author:** ![Quintin\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/13edae/32.png) [@Quintin\_P](https://www.ruby-forum.com/u/Quintin_P)\ **Post date:** [February 10, 2012, 3:18pm UTC](https://www.ruby-forum.com/t/old-thread-cache-for-non-cookie-users-and-fresh-for-cookie-users/216607/6 "2012-02-10T15:18:06Z")
On 10 Fev 2012 08h34 WET, [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > [http://nginx.2469901.n2.nabble.com/Help-cache-or-not-by-cookie-td3124462.html](http://nginx.2469901.n2.nabble.com/Help-cache-or-not-by-cookie-td3124462.html) > > > > > 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? The easiest and fastest way is to delete the file. You need to build a function in a programming language (PHP, Lua, Ruby) that computes the key: In PHP: $filename = md5(‘[example.com/foobar](http://example.com/foobar)’); This is for a key like: ``` $host$request_uri ``` Then depending on the structure if your cache directory each directory is named by taking a number of characters from the end of the string: For the above: $filename is 536d75ab92a8e8778916a971cb1fb4e0 If the cache dir structure is something like: proxy\_cache\_path /var/cache/nginx/microcache levels=1:2 keys\_zone=microcache:5M max\_size=1G; ^^^ This means that the path to the file containing the cached page will be: /var/cache/nginx/microcache/0/4e/536d75ab92a8e8778916a971cb1fb4e0 where: 0 is substr($filename, -1, 1) ^ 1 from levels=1:2 4e is substr($filename, -3, 2) ^ 2 from levels=1:2 HTH, — appa ---
**Author:** ![Quintin\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/13edae/32.png) [@Quintin\_P](https://www.ruby-forum.com/u/Quintin_P)\ **Post date:** [February 11, 2012, 9:09am UTC](https://www.ruby-forum.com/t/old-thread-cache-for-non-cookie-users-and-fresh-for-cookie-users/216607/7 "2012-02-11T09:09:34Z")
On 10 Fev 2012 14h45 WET, [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > # Turn caching on for POST method request responses as well > > # for a match in the cache, and if that fails, by passing > > proxy\_pass $scheme://backend; > 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. > **[GitHub - nginxinc/nginx-wiki: ARCHIVED -- Source for the now archived NGINX Wiki...](https://github.com/nginxinc/nginx-wiki)** > > ARCHIVED -- Source for the now archived NGINX Wiki section of https://www.nginx.com > **[GitHub - nginxinc/nginx-wiki: ARCHIVED -- Source for the now archived NGINX Wiki...](https://github.com/nginxinc/nginx-wiki)** > > ARCHIVED -- Source for the now archived NGINX Wiki section of https://www.nginx.com BTW: Valentin, Maxim, Igor, Andrei, et al The proxy\_cache\_methods and fastcgi\_cache\_methods are missing on the official docs at > **[Module ngx\_http\_proxy\_module](http://nginx.org/en/docs/http/ngx_http_proxy_module.html)** and [Module ngx\_http\_fastcgi\_module](http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html) respectively. — appa ---
**Author:** ![Quintin\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/13edae/32.png) [@Quintin\_P](https://www.ruby-forum.com/u/Quintin_P)\ **Post date:** [February 11, 2012, 9:30am UTC](https://www.ruby-forum.com/t/old-thread-cache-for-non-cookie-users-and-fresh-for-cookie-users/216607/8 "2012-02-11T09:30:34Z")
On Feb 10, 2012, at 7:05 PM, Antnio P. P. Almeida wrote: > Why all this? The default behavior is for POSTed requests never to be > cached. > > [GitHub - nginxinc/nginx-wiki: ARCHIVED -- Source for the now archived NGINX Wiki section of https://www.nginx.com · GitHub](http://wiki.nginx.org/HttpProxyModule#proxy_cache_methods) > > [GitHub - nginxinc/nginx-wiki: ARCHIVED -- Source for the now archived NGINX Wiki section of https://www.nginx.com · GitHub](http://wiki.nginx.org/HttpFcgiModule#fastcgi_cache_methods) > > BTW: Valentin, Maxim, Igor, Andrei, et al Right, thanks for spotting this one. We’re currently working on sync’ing it up it all up and making the entire thing less confusing. ---
**Author:** ![Quintin\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/13edae/32.png) [@Quintin\_P](https://www.ruby-forum.com/u/Quintin_P)\ **Post date:** [February 11, 2012, 9:44am UTC](https://www.ruby-forum.com/t/old-thread-cache-for-non-cookie-users-and-fresh-for-cookie-users/216607/9 "2012-02-11T09:44:49Z")
10 февраля 2012, 19:06 от António P. P. Almeida [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): > > proxy\_cache\_key $scheme$host$uri; > > > > # Pass the POST method request directly to the backend > > > > 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 ---
**Author:** ![Quintin\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/13edae/32.png) [@Quintin\_P](https://www.ruby-forum.com/u/Quintin_P)\ **Post date:** [February 11, 2012, 8:49am UTC](https://www.ruby-forum.com/t/old-thread-cache-for-non-cookie-users-and-fresh-for-cookie-users/216607/10 "2012-02-11T08:49:13Z")
10 февраля 2012, 12:35 от Quintin P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): > > > “No, currently the single way is: > > > “Sets when to expire the file in the internal Nginx cache, if one is > > 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 ---
**Author:** ![Quintin\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/13edae/32.png) [@Quintin\_P](https://www.ruby-forum.com/u/Quintin_P)\ **Post date:** [February 11, 2012, 10:46am UTC](https://www.ruby-forum.com/t/old-thread-cache-for-non-cookie-users-and-fresh-for-cookie-users/216607/11 "2012-02-11T10:46:41Z")
On 10 Fev 2012 15h41 WET, [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > # 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; You’re saying the POST is a valid method for caching, i.e., POSTed requests get cached. > > > proxy\_pass $scheme://backend; > > > } Here you do an internal redirect to @post\_and\_refresh\_cache via error\_page when the request method is a POST. > > > 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; > > > } Here you bypass the cache and proxy\_pass the request to a backend. AFAICT you’re replicating the _default_ behaviour which is to not cache in the case of POST requests. Is it not? — appa ---
**Author:** ![Quintin\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/13edae/32.png) [@Quintin\_P](https://www.ruby-forum.com/u/Quintin_P)\ **Post date:** [February 11, 2012, 11:51am UTC](https://www.ruby-forum.com/t/old-thread-cache-for-non-cookie-users-and-fresh-for-cookie-users/216607/12 "2012-02-11T11:51:05Z")
10 февраля 2012, 20:43 от António P. P. Almeida [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): > On 10 Fev 2012 15h41 WET, [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > 10 февраля 2012, 19:06 от António P. P. Almeida [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): > > > > > On 10 Fev 2012 14h45 WET, [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > > > > > > # Turn caching on for POST method request responses as well > > > > > > > > proxy\_cache\_methods GET HEAD POST; > > You’re saying the POST is a valid method for caching, i.e., POSTed > requests get cached. The proxy\_cache\_methods directive is used to select the request methods that will have their responses cached. By default, nginx caches only GET and HEAD request method responses, which is why I added the POST request method to the list - so that POST method request responses would be cached as well. This is necessary if you want to make sure the cache is instantly refreshed whenever you update something through a POST method request. Without this directive here, you would update the content on the backend, but the frontend would hold and serve the stale content from the cache until its validity expired instead of the new, updated content that’s on the backend. > > > > proxy\_pass $scheme://backend; > > > > } > > Here you do an internal redirect to @post\_and\_refresh\_cache via > error\_page when the request method is a POST. Exactly. > > > > 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; > > > > } > > Here you bypass the cache and proxy\_pass the request to a backend. Exactly. > AFAICT you’re replicating the _default_ behaviour which is to not > cache in the case of POST requests. Is it not? The default behaviour is not to cache POST method request responses, but I turned caching of POST method request responses ON, so I had to make sure the cache is bypassed for POST method requests (but not for GET or HEAD method requests!). All POST method requests are passed on to the backend without checking for a match in the cache, but - CONTRARY to the default behavior - all POST method request responses are cached. Without the @post\_and\_refresh\_cache location block and without the proxy\_cache\_bypass directive, nginx would check the cache and return the content from the cache (put there by a previous GET request response, for example) and would not pass the POST method request on to the backend, which is definitely not what you want in this case. Max ---
**Author:** ![Quintin\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/13edae/32.png) [@Quintin\_P](https://www.ruby-forum.com/u/Quintin_P)\ **Post date:** [February 11, 2012, 4:28pm UTC](https://www.ruby-forum.com/t/old-thread-cache-for-non-cookie-users-and-fresh-for-cookie-users/216607/13 "2012-02-11T16:28:04Z")
On 10 February 2012 20:47, Max [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > and return the content from the cache (put there by a previous > GET request response, for example) and would not pass the POST > method request on to the backend, which is definitely not what > you want in this case. Your config would do what the OP wanted but it would be nicer, I think, if the POST request simply invalidated the existing cached content and then for the content to be cached only if and when there is a GET request for that item. I.E., for the cache validity to start when there is a request to view the item. Also avoids using $uri as key which can lead to cache pollution with frontend controllers etc. An internal call to a proxy\_purge location could do this … maybe as a post\_action. There will be no need for the proxy\_bypass ---
**Author:** ![Quintin\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/13edae/32.png) [@Quintin\_P](https://www.ruby-forum.com/u/Quintin_P)\ **Post date:** [February 11, 2012, 6:09pm UTC](https://www.ruby-forum.com/t/old-thread-cache-for-non-cookie-users-and-fresh-for-cookie-users/216607/14 "2012-02-11T18:09:47Z")
On 10 Fev 2012 17h47 WET, [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > the proxy\_cache\_bypass directive, nginx would check the cache > and return the content from the cache (put there by a previous > GET request response, for example) and would not pass the POST > method request on to the backend, which is definitely not what > you want in this case. If what the OP wanted was to distinguish between cached POST and GET request responses then just add $request\_method to the cache key. — appa ---
**Author:** ![Quintin\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/13edae/32.png) [@Quintin\_P](https://www.ruby-forum.com/u/Quintin_P)\ **Post date:** [February 11, 2012, 8:57pm UTC](https://www.ruby-forum.com/t/old-thread-cache-for-non-cookie-users-and-fresh-for-cookie-users/216607/15 "2012-02-11T20:57:42Z")
11 февраля 2012, 18:49 от Quintin P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): > 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 S.'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 ---
**Author:** ![Quintin\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/13edae/32.png) [@Quintin\_P](https://www.ruby-forum.com/u/Quintin_P)\ **Post date:** [February 11, 2012, 8:03pm UTC](https://www.ruby-forum.com/t/old-thread-cache-for-non-cookie-users-and-fresh-for-cookie-users/216607/16 "2012-02-11T20:03:48Z")
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? I might sound a bit naïve here, but all the different proxy\_cache mechanisms seems to get a bit confusing. To the reason why I don’t want nginx\_ngx\_cache\_purge: Recompiling and delivering through the yum repo of a large organization is a cumbersome process and raises many flags. -Q ---
**Author:** ![Quintin\_P](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/q/13edae/32.png) [@Quintin\_P](https://www.ruby-forum.com/u/Quintin_P)\ **Post date:** [February 12, 2012, 12:15pm UTC](https://www.ruby-forum.com/t/old-thread-cache-for-non-cookie-users-and-fresh-for-cookie-users/216607/17 "2012-02-12T12:15:12Z")
11 февраля 2012, 02:25 от Nginx U. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):