Nginx doesn't honor Cache-Control: no-cache _request_
杨镭
clanherb at gmail.com
Mon Mar 1 21:09:53 MSK 2010
强制刷新 (shift + reload) nginx不支持。但nginx作者有自己的意见,详见igor的解释。
这个我觉得都有道理
2009/8/4 Mirosław Jaworski <mjaw at ikp.pl>
> On Mon, 2009-08-03 at 16:34 +0400, Igor Sysoev wrote:
> > > > No, currently nginx ignores the reload because everyone may flush
> > > > popular and heavy generated pages from your cache.
> > > > I plan to allow reload only from limited set of addresses.
> > >
> > > Cache-control: no-cache request isn't supposed to revalidate/invalidate
> > > cache.
> > >
> > > Logic is fairly trivial - exactly as i showed in my nonexisting
> > > variable/wrong syntax example - nginx should simply omit checking
> > > the cache when receiving such request, go for the backend and serve
> > > backend's response without doing anything to the cache.
> >
> > RFC does not say that server must not cache this response, it just says
> > that is must bot use previously cached response.
>
> Yet nginx does use cached response, breaking it. That's the most
> important part which needs addressing.
>
> My suggestion not only complies with RFC but also allows to avoid
> treating "Cache-control: no-cache" request as uncontrollable way to
> tamper with the cache.
>
> > Anyway, "Cache-control" should be supported from trusted addresses only:
> > nginx is not generic transit proxy, it's accelerator, it's just part
> > of web-server.
>
> And should comply with RFC as such. It may be a nice _feature_
> for some to limit it using some cache_control_restrict though.
>
> Back to the problem - if i can't use cache depend on some request
> header, can i make it IP dependent?
>
> --
> Mirosław "Psyborg" Jaworski
> GCS/IT d- s+:+ a C++$ UBI++++$ P+++$ L- E--- W++(+++)$ N++ o+ K- w-- O-
> M- V- PS+ PE++ Y+ PGP t 5? X+ R++ !tv b++(+++) DI++ D+ G e* h++ r+++ y?
> "If at first you don't succeed, redefine success."
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20100302/602fcf5b/attachment-0001.html>
More information about the nginx
mailing list