Old thread: Cache for non-cookie users and fresh for cookie users
Quintin Par
quintinpar at gmail.com
Sat Feb 11 14:49:06 UTC 2012
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
On Sat, Feb 11, 2012 at 5:36 AM, António P. P. Almeida <appa at perusio.net>wrote:
> On 10 Fev 2012 17h47 WET, nginxyz at mail.ru wrote:
>
> >
> > 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.
>
> 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
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20120211/4cd841ca/attachment.html>
More information about the nginx
mailing list