Invalidate cache for static files?

[Phillip B Oldham]

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.

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.

------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: phill.vcf
Type: text/x-vcard
Size: 261 bytes
Desc: not available
URL: <http://nginx.org/pipermail/nginx/attachments/20080721/0038409b/attachment.vcf>