Invalidate cache for static files?

[Igor Sysoev]

On Mon, Jul 21, 2008 at 04:35:30PM +0100, Phillip B Oldham wrote:

> I don't think moving/renaming files would be a great option. There are a 
> lot of files to manage, and a lot of links to them in the source. Would 
> be a bit of a nightmare.
> 
> It would be useful if nginx supported Etags based on last modified time. 
> Especially if the etag could be cached and a customer signal could be 
> passed to nginx to clear this cache.

nginx supports Last-Modified header. However, Last-Modified as well as ETag
do not help to invalide browsers' cache.

> Denis Arh wrote:
> >Would it help moving them into a different folder instead of appending 
> >query string?
> >
> >Sent from my iPhone
> >
> >On 21.7.2008, at 16:55, Tit Petric <black at scene-si.org> wrote:
> >
> >>
> >>
> >>Maxim Dounin wrote:
> >>>Hello!
> >>>
> >>>On Mon, Jul 21, 2008 at 01:57:06PM +0100, Phillip B Oldham wrote:
> >>>
> >>>>What would be the simplest way to invalidate browser cache of 
> >>>>static  files served by nginx?
> >>>>
> >>>>For instance, we have a website which is in active development. We 
> >>>>get a  reasonable amount of traffic, but we often get complaints 
> >>>>when we update  the live files because some browsers are working 
> >>>>with a mix of fresh  (live) and stale (cached) js/css files. We'd 
> >>>>like to inform/force  browsers that the file is new and should be 
> >>>>updated.
> >>>
> >>>Just use normal web development practices, e.g. add "?v=<version>"
> >>>to js/css urls.  Nothing special, nginx is just web server.
> >>I've tried this before, it is problematic since cache doesn't behave 
> >>correctly and in some cases browsers or even caching proxies in front 
> >>of backend servers never cache the resource, because they percieve 
> >>the link as dynamic.
> >>
> >>Having unique urls, like I suggested in the previous email, solves 
> >>theese problems. Also, you can then set the Expires & Cache-control 
> >>headers for static content far in the future and encourage browser 
> >>caching, since you have an effective method of always reloading them 
> >>without fail. Caches and browsers will keep such objects, while the 
> >>suggested sollution with the "?v=version" will not be cached on many 
> >>of them, since they percieve the url as dynamic and always try a 
> >>reload, ignoring possible Expires & Cache-control headers.
> >>
> >>For a small setup, where you don't care about resources, your 
> >>sollution is mostly fine, but is problematic in the real world with 
> >>tens of thousands of users.
> >>
> >>BR
> >>
> >
> >
> 
> -- 
> 
> *Phillip B Oldham*
> The Activity People
> phill at theactivitypeople.co.uk <mailto:phill at theactivitypeople.co.uk>
> 
> ------------------------------------------------------------------------
> 
> *Policies*
> 
> This e-mail and its attachments are intended for the above named 
> recipient(s) only and may be confidential. If they have come to you in 
> error, please reply to this e-mail and highlight the error. No action 
> should be taken regarding content, nor must you copy or show them to anyone.
> 
> This e-mail has been created in the knowledge that Internet e-mail is 
> not a 100% secure communications medium, and we have taken steps to 
> ensure that this e-mail and attachments are free from any virus. We must 
> advise that in keeping with good computing practice the recipient should 
> ensure they are completely virus free, and that you understand and 
> observe the lack of security when e-mailing us.
> 
> ------------------------------------------------------------------------

> begin:vcard
> fn:Phillip Oldham
> n:Oldham;Phillip
> org:The Activity People;Systems Development
> email;internet:phill at theactivitypeople.co.uk
> title:Chief Programmer
> tel;work:0870 162 4847
> x-mozilla-html:TRUE
> url:http://theactivitypeople.co.uk/
> version:2.1
> end:vcard
> 


-- 
Igor Sysoev
http://sysoev.ru/en/