Invalidate cache for static files?

[Mansoor Peerbhoy]

Oh I forgot.

In case the browser gets back a 304 response for a static resource, then it loads it from its cache
But you may have trouble with "certain" <hint> browsers even after theory says it should re-fetch

M

----- "Mansoor Peerbhoy" <mansoor at zimbra.com> wrote:

| From: "Mansoor Peerbhoy" <mansoor at zimbra.com>
| To: nginx at sysoev.ru
| Sent: Monday, July 21, 2008 9:13:55 PM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi
| Subject: Re: Invalidate cache for static files?
|
| Hi
| 
| Have you tried suppressing the Last-Modified response header ?
| Usually, when a web server serves a static page, it uses the mtime of
| the file to send back the Last-Modified response header.
| 
| When the browser loads the static file, let's say at time X, it may
| get back the response header Last-Modified: Y
| 
| Then, subsequently, when the browser wants the page again, it sends
| the If-Modified-Since request header, containing X
| And, if the file has not been modified in the interval since X, then
| the web server sends back the HTTP not modified response (304)
| 
| Does NGINX send back the Last-Modified header for static resources ? I
| guess it should.
| Also, if NGINX allows you to suppress a response header on the way
| out, then you should use that config directive to suppress the
| Last-Modified header.
| 
| I believe that should cause the browser to reload the resource every
| time, though one can't be sure about these things
| 
| Regards,
| Mansoor
| 
| ----- "Denis Arh" <denis at arh.cc> wrote:
| 
| | From: "Denis Arh" <denis at arh.cc>
| | To: nginx at sysoev.ru
| | Sent: Monday, July 21, 2008 8:31:16 PM GMT +05:30 Chennai, Kolkata,
| Mumbai, New Delhi
| | Subject: Re: Invalidate cache for static files?
| |
| | 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
| | >