Nginx doesn't honor Cache-Control: no-cache _request_

[pf shineyear]

不过NGINX本身也没有支持对后端的 ims

如果后端的源数据没有更新, 即时缓存过期了也不应该更新才对

这个SQUID是有的, 不知道NGINX什么时候可以有

On Tue, Mar 2, 2010 at 2:09 AM, 杨镭 <clanherb at gmail.com> wrote:

> 强制刷新 （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."
>>
>>
>>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://nginx.org/mailman/listinfo/nginx
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20100308/dd449e83/attachment.html>