Web Tricks: Forced Static Refresh
Given
There is a website you manage and you have full access to its file structure. For some reason, this site is not indifferent to you: perhaps it is a reflection of your alter ego, or serves as a platform for political statements, or just stupidly generates you money for beer. Anyway, from time to time you feel the need to sit at the computer and bring another improvement to the work of the site, be it a convenient widget, a set of cool icons or a useful plugin.
Situation
')
You have just radically reworked the page template (aligned jigsaws, changed colors, registered background images). It turned out really cool! It's time to upload changes to the server. You launch an FTP client, drag gifs and css from the left panel to the right and, all so pleased, open the website in your favorite browser ...
"MOTHER! Mother! mother! ”echo echoed out of habit.
What na? Where did it all go? Why are blocks stacked on top of one another? Where does this blue strip come from? What a stupid font?
A thought explodes in my head: “Blah, this is the damning thing that the whole world now sees! Well, not all, but at least that part of it that goes to my site! What to do, your mother, what to do? ”.
Chill out! Do not panic. Nothing bad happened. Everything is good.
Get out of zagashnik any stale browser that you have not used for a hundred years. What have you got, Netscaf? Simanki? Eighth Opera? It doesn't matter, it will go. Open the website. Well, relieved? Everything looks as it should be? Right. This is how all new visitors see your site now. A mess in your favorite browser - due to the fact that the old contents of the CSS file is preserved in the browser cache, and all those styles that you have been rubbing over the last two days have not yet reached your computer. By the way, to correct this matter of treating a lung is as simple as pressing Ctrl + F5.
Another thing is that not all visitors are so advanced, and it is likely that some of them will be forced to contemplate the picture that has moved for a long time. Just write a hint: “Citizens, from whom the site looks crooked, press Ctrl + F5”.
Or maybe there is a better way? Is it possible to somehow force the browser to forcibly refresh the cache?
Looking ahead, I can make you happy: there is such a way! Moreover, the way to the disgrace simple, one hundred percent valid and completely trouble-free. However, first things first. Seriously, it will be more useful.
Analysis
So, the browser and its cache. What determines whether the browser will go for new content or get an old copy? From many factors, in fact. From browser type. From the version. From the platform. From user settings. From with what HTTP headers from the server static is given. From the presence of proxies on the path between the web server and your computer. In short, a lot of what. Is there any control over this whole economy? Is it possible to give them all the team to score on the cache and in a friendly way rush over the new content?
The short answer is no. But there are options. Which we now consider.
1. HTTP Cache-Control Header
Theoretically, it would be possible to accompany static resources returned from the server with the following header:
This would ensure that the client uses the actual contents of the server files. Unfortunately, this method has a significant drawback: it creates an excessive (and unnecessary) load on the network and other resources: after all, every time you request a page, the browser will have to reload the accompanying statics: style files, JavaScript scripts and graphics. In addition, not everyone can and does not always have the ability to manage HTTP headers.
You can also specify a different header value, for example:
This, as you understand, the directive to keep a copy in the cache for a day, but this does not solve the problem: if the user went to the site (the static was in the cache), and you changed the file after that, until tomorrow this will not know, and will be forced to admire the inappropriately moved layout.
2. HTTP Last-Modified Header
In principle, most servers automatically prescribe this header when returning static resources. This allows the browser to upload new content only if the file has actually been modified. To do this, along with the GET request, the browser sends the header:
And then the server looks at the date of the change of the corresponding file, and if nothing has changed, it answers with the status code 304. Such an interaction scheme somewhat reduces the load on the network, but, unfortunately, does not give any guarantee that the browser will decide to inquire about this file.
So how do you get him the desired behavior? For this there is a radical means, namely:
3. Rename file
In fact, if we in the body of an HTML document refer to our style file by a new name, for example style1.css instead of style.css, then for the browser it will definitely be another resource that he will have to go and pick up directly from the server.
Hooray! Problem solved!
However, do not rush to rejoice. Renaming a file removes one problem, but generates a lot of other equally unpleasant ones. Even from purely practical considerations, it is very inconvenient to have such a “stray” file in the project, but it’s not the only one! After all, we have a development environment set up, there is a version control system - and they are not really designed to work with constantly renamed files.
But wait, but what if ... What if you change not the file, but ... But of course! Eureka!
4. Rename URL
Recall that the URL may contain, in addition to the file name, a bunch of different components. For example, the Query String is the part that comes after the question mark. Thought it was good only for forum engines: /index.php?showthread=1234? But they did not guess. Who wants, he will take advantage. For example, we are for our style file. How about registering such a line:
Handsomely? And then! See what happens. The browser downloads the HTML code for the page. See pointer to style sheet. Looks at the URL: /style.css?ver=123. Checks in the cache and finds the old version: /style.css?ver=122. For the browser, these are two completely different addresses, so he did not hesitate to issue a GET request to receive a new CSS file.
Now comes the web server. He analyzes the server address of the resource and determines that a static style.css file is requested, and if so, the tail part of the URL is sent to it on the drum. Therefore, he takes and with a clear conscience gives the client the contents of the specified file - the one that you just changed.
Telemarket!
In fact, this approach can be diversified with many modifications - for example, use an even simpler address like /style.css?123, or use server code that will automatically convert the date of file change to a string and substitute it as a tail. But this is all the details. The main thing is that you now know how to ensure adequate page display after changing styles.
Good luck in site building!
Update
During the discussion of the article, some ideas were expressed that deserve a separate mention. In particular:
1. Some browsers (primarily IE 6+) do not cache pages with URLs in their URLs.
Not true. Quite a cache. Kilometers of logs were viewed on various sites with different configurations, and I can responsibly state that there is no notice that there is no browser that basically does not cache pages with a shank in the address. Further examination of the issue in the internet showed that for confidence, it is desirable to give statics with explicitly written Cache-Control caching directives, and then the question is almost completely removed.
2. It is better to modify not the variable, but the constant part of the URL address, and use mod_rewrite to redirect to a permanent file.
What can be said about this: an absolutely working solution that removes all issues with caching on the client. It is strongly recommended to anyone who has access to the mod-rewrite configuration. However, in situations where access to the files of the website is all that you have available, you are completely satisfied with the way the variables in the URL are set out in the note.
3. To do all the renaming in the framework of the process of automatic assembly and deployment of the project.
Comrades! This note is least of all addressed to people involved in the streaming development of web software. If everything is so complete with you that the site is depressed at the touch of a button, such things as renaming statics should be known to you a hundred pounds.
Note: “Web Tricks” is a mini-series in which I share bits and pieces of the webmaster's experience, acquired over a more than five-year history of maintenance and development of the author’s project English without fools .
There is a website you manage and you have full access to its file structure. For some reason, this site is not indifferent to you: perhaps it is a reflection of your alter ego, or serves as a platform for political statements, or just stupidly generates you money for beer. Anyway, from time to time you feel the need to sit at the computer and bring another improvement to the work of the site, be it a convenient widget, a set of cool icons or a useful plugin.
Situation
')
You have just radically reworked the page template (aligned jigsaws, changed colors, registered background images). It turned out really cool! It's time to upload changes to the server. You launch an FTP client, drag gifs and css from the left panel to the right and, all so pleased, open the website in your favorite browser ...
"MOTHER! Mother! mother! ”echo echoed out of habit.
What na? Where did it all go? Why are blocks stacked on top of one another? Where does this blue strip come from? What a stupid font?
A thought explodes in my head: “Blah, this is the damning thing that the whole world now sees! Well, not all, but at least that part of it that goes to my site! What to do, your mother, what to do? ”.
Chill out! Do not panic. Nothing bad happened. Everything is good.
Get out of zagashnik any stale browser that you have not used for a hundred years. What have you got, Netscaf? Simanki? Eighth Opera? It doesn't matter, it will go. Open the website. Well, relieved? Everything looks as it should be? Right. This is how all new visitors see your site now. A mess in your favorite browser - due to the fact that the old contents of the CSS file is preserved in the browser cache, and all those styles that you have been rubbing over the last two days have not yet reached your computer. By the way, to correct this matter of treating a lung is as simple as pressing Ctrl + F5.
Another thing is that not all visitors are so advanced, and it is likely that some of them will be forced to contemplate the picture that has moved for a long time. Just write a hint: “Citizens, from whom the site looks crooked, press Ctrl + F5”.
Or maybe there is a better way? Is it possible to somehow force the browser to forcibly refresh the cache?
Looking ahead, I can make you happy: there is such a way! Moreover, the way to the disgrace simple, one hundred percent valid and completely trouble-free. However, first things first. Seriously, it will be more useful.
Analysis
So, the browser and its cache. What determines whether the browser will go for new content or get an old copy? From many factors, in fact. From browser type. From the version. From the platform. From user settings. From with what HTTP headers from the server static is given. From the presence of proxies on the path between the web server and your computer. In short, a lot of what. Is there any control over this whole economy? Is it possible to give them all the team to score on the cache and in a friendly way rush over the new content?
The short answer is no. But there are options. Which we now consider.
1. HTTP Cache-Control Header
Theoretically, it would be possible to accompany static resources returned from the server with the following header:
Cache-Control: no-cacheThis would ensure that the client uses the actual contents of the server files. Unfortunately, this method has a significant drawback: it creates an excessive (and unnecessary) load on the network and other resources: after all, every time you request a page, the browser will have to reload the accompanying statics: style files, JavaScript scripts and graphics. In addition, not everyone can and does not always have the ability to manage HTTP headers.
You can also specify a different header value, for example:
Cache-Control: max-age=86400This, as you understand, the directive to keep a copy in the cache for a day, but this does not solve the problem: if the user went to the site (the static was in the cache), and you changed the file after that, until tomorrow this will not know, and will be forced to admire the inappropriately moved layout.
2. HTTP Last-Modified Header
In principle, most servers automatically prescribe this header when returning static resources. This allows the browser to upload new content only if the file has actually been modified. To do this, along with the GET request, the browser sends the header:
If-Modified-Since: Tue, 23 Jun 2009 19:12:47 GMTAnd then the server looks at the date of the change of the corresponding file, and if nothing has changed, it answers with the status code 304. Such an interaction scheme somewhat reduces the load on the network, but, unfortunately, does not give any guarantee that the browser will decide to inquire about this file.
So how do you get him the desired behavior? For this there is a radical means, namely:
3. Rename file
In fact, if we in the body of an HTML document refer to our style file by a new name, for example style1.css instead of style.css, then for the browser it will definitely be another resource that he will have to go and pick up directly from the server.
Hooray! Problem solved!
However, do not rush to rejoice. Renaming a file removes one problem, but generates a lot of other equally unpleasant ones. Even from purely practical considerations, it is very inconvenient to have such a “stray” file in the project, but it’s not the only one! After all, we have a development environment set up, there is a version control system - and they are not really designed to work with constantly renamed files.
But wait, but what if ... What if you change not the file, but ... But of course! Eureka!
4. Rename URL
Recall that the URL may contain, in addition to the file name, a bunch of different components. For example, the Query String is the part that comes after the question mark. Thought it was good only for forum engines: /index.php?showthread=1234? But they did not guess. Who wants, he will take advantage. For example, we are for our style file. How about registering such a line:
<link rel="stylesheet" href="/style.css?ver=123" type="text/css" />Handsomely? And then! See what happens. The browser downloads the HTML code for the page. See pointer to style sheet. Looks at the URL: /style.css?ver=123. Checks in the cache and finds the old version: /style.css?ver=122. For the browser, these are two completely different addresses, so he did not hesitate to issue a GET request to receive a new CSS file.
Now comes the web server. He analyzes the server address of the resource and determines that a static style.css file is requested, and if so, the tail part of the URL is sent to it on the drum. Therefore, he takes and with a clear conscience gives the client the contents of the specified file - the one that you just changed.
Telemarket!
In fact, this approach can be diversified with many modifications - for example, use an even simpler address like /style.css?123, or use server code that will automatically convert the date of file change to a string and substitute it as a tail. But this is all the details. The main thing is that you now know how to ensure adequate page display after changing styles.
Good luck in site building!
Update
During the discussion of the article, some ideas were expressed that deserve a separate mention. In particular:
1. Some browsers (primarily IE 6+) do not cache pages with URLs in their URLs.
Not true. Quite a cache. Kilometers of logs were viewed on various sites with different configurations, and I can responsibly state that there is no notice that there is no browser that basically does not cache pages with a shank in the address. Further examination of the issue in the internet showed that for confidence, it is desirable to give statics with explicitly written Cache-Control caching directives, and then the question is almost completely removed.
2. It is better to modify not the variable, but the constant part of the URL address, and use mod_rewrite to redirect to a permanent file.
What can be said about this: an absolutely working solution that removes all issues with caching on the client. It is strongly recommended to anyone who has access to the mod-rewrite configuration. However, in situations where access to the files of the website is all that you have available, you are completely satisfied with the way the variables in the URL are set out in the note.
3. To do all the renaming in the framework of the process of automatic assembly and deployment of the project.
Comrades! This note is least of all addressed to people involved in the streaming development of web software. If everything is so complete with you that the site is depressed at the touch of a button, such things as renaming statics should be known to you a hundred pounds.
Note: “Web Tricks” is a mini-series in which I share bits and pieces of the webmaster's experience, acquired over a more than five-year history of maintenance and development of the author’s project English without fools .
Source: https://habr.com/ru/post/62844/
All Articles