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
I believe that should cause the browser to reload the resource every
time, though one can’t be sure about these things
----- “Denis Arh” [email protected] wrote:
| From: “Denis Arh” [email protected]
| To: [email protected]
| 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 P. [email protected] wrote:
| > Maxim D. 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=”
| >> 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