I have this problem with my web server will not reload our javascript files when we eg overwrite with a new one, if for example, we have made a mistake in the previous file.
If we just throw a file on top of the same name, update the file does not, we will have to create a new file with a different name.
Anyone have a solution to it?
It has nothing to do with Ubuntu nor JavaScript, but browser (or server?) caching.
The simplest way to force the non-cached version to be used is to add a version to your file when you update it, using a query string like this:
<script src="myScript.js?v=2"></script>
If you wish to always force the non-cached version, you can use the timestamp instead and get something like:
<script src="myScript.js?t=1407845240"></script>
Browsers will see these are different files and always load them from scratch. Both t and v are custom variables, so you can use whatever you want there - it's important that their value changes with each new version of the file (or automatic, if you're using the timestamp method).
Ctrl+F5 in your browser to refresh the page will force it to get your new JS file.
Related
SCENARIO:
I am trying to come up with a way to Version Control in JS that fulfills two premises:
Cache-wise
Few (or none ideally) calls to Backend
Therefore I came up with this scheme:
I need FE to reload contents everytime a new version is available, so a simple way to achieve this would be to add a version tag to src link:
<script type="text/javascript" src="myfile.js?15.6.0"></script>
I can add some templating, so the version number can be defined elsewhere, like:
<script type="text/javascript" src="myfile.js?$$RELEASE_ID$$"></script>
PROBLEM:
I would need to call the Backend, to know the latest version (and the Backend will read it from pom.xml file, returning it afterwards)
QUESTION:
Is there any way I can use so the Front End knows what is the latest version?
Thanks.
I'd use buildnumber-maven-plugin to generate a version tag, e.g. git hash. And, embed it somewhere in a war file. Either
It's a server side file, e.g. web.xml where you can define a context variable for access in your Java code, or
An HTML/JS file for browser side.
See https://github.com/renfeng/event-manager/blob/master/pom.xml#L130-L155
There is no way to eliminate communication with back end in order to get information about a state of a file on the server. But if you desire to have as few requests as possible, you could set an intervals for your FE to poll the server.
If you usually release BE version every day, it makes since to poll server any change every 12, 6 ,4 or any number of hours you want. It all depends on how crucial it is to update the file.
That been said, in most cases when updating a file version on back end, once page is refreshed (which is likely to happen after few hours) the server will send the new file version, unless server caching strategy is configured otherwise.
I have added a pretty substantial change to a javascript file. However, in order for the new changes to register, I need to refresh my browser. I imagine this is how it will be for all the other people using this site as well.
Is there a way to invalidate the client's browser cache and force it to download the new js file?
You can rename the file, or just add a random parameter when loading the file:
<script src="/javascripts/application.js?version=4" type="text/javascript"></script>
You can add an argument to the file name, like
<script src="script.js?rnd=2131231"></script>
There is a very comprehensive discussion here, with several ways to do this.
The recommended solution (mod_pagespeed) might not be the best solution for you in case your project is not big enough or you don't use apache, in which case I would recommend a format such as:
<script src="/{sha_1_here}/script.js"></script>
instead of a GET parameter, because apparently some browsers do not cache scripts with parameters.
This should work everywhere, and you just need to rewrite the URL server side.
For development purposes, I disable the cache on the browser side so that it fetches always.
But for production, to reset so that all client user's browsers should download the new version you can look at apache's settings to expire cached files.
So I changed some jquery on a page in my application and it works fine etc.
But I just noticed that when I push the code to a different server and run the page on that server I need to hit ctrl + f5 to see the changes reflected. Is there a way when doing a code push to clear the cache on that page / javascript so it loads the latest version not the cached version.
on your referenced javascript file you can add a querystring, like:
<script src="/scripts/myfile.js?v=1" type="text/javascript"></script>
whenever you change the text in the file update the query string.
You need to take a look at your js files content expiry.
One way to solve this problem is to append a dummy query string parameter to all your *.js urls and set it to the build number of your app or file modified time.
/Scripts/file.js?v=1.0.12345.0
This will ensure that each build will use new urls and you can set their content expiry to never.
I'm using CKEditor which is a multi-file library so the main js file calls other js and css files. I'm noticing that after the main file is called, additional files have a ?t=CODE added to them, so something like this, but the actual files don't have that extra ?t=B49E5BQ at the end.
http://site.com/ckeditor/config.js?t=B49E5BQ
http://site.com/ckeditor/extra.js?t=B49E5BQ
What's the point of this
P.S. Please feel free to add additional tags, because I'm not sure about this one.
This sort of trailing data is sometimes put into URLs for resources files like scripts/stylesheets so as to prevent caching of resources across re-deployments.
Whenever you change a resource, you change the code in HTML files/templates which require that resource, so that clients re-request the resource from the server the next time they load the page.
I would guess that the URL parameter is added to bypass any caching mechanisms. When a client sees the same URL with a different query parameter, that usually means the client can't use the cached version of the resource (in this case a JS file) and go to the server to fetch the latest version.
In HTTP, if a URL is the same in every way except for the URL parameters, a client can not assume that those files/resources are the same resulting object.
Which means:
http://site.com/ckeditor/config.js?t=B49E5BQ
is not the same as:
http://site.com/ckeditor/config.js?t=1234
It must be there to prevent caching.
I do this occasionally for images and script files. In my case, it's a meaningless argument (usually datetime) that just forces the browser to fetch a new copy every time.
If the parameter keeps changing, those files won't be cached on the client side.
Often this is easier than say, changing the name of the file to include a version number (jquery-1.6.2.js works nicely, but do you want to rename config.js to config-1.0.js, -2.0, etc. every time you make a change?
Like all the other answers, this simply forces the browser to grab the latest version when the querystring (?t=B49E5BQ) is changed. In our case, we simply add the date (?06022011).
If this has been asked before, I apologize but this is kinda of a hard question to search for. This is the first time I have come across this in all my years of web development, so I'm pretty curious.
I am editing some HTML files for a website, and I have noticed that in the src attribute of the script tags that the previous author appended a question mark followed by data.
Ex: <script src="./js/somefile.js?version=3.2"></script>
I know that this is used in some languages for value passing in GET request, such as PHP, but as I far as I ever knew, this wasn't done in javascript - at least in calling a javascript file. Does anyone know what this does, if anything?
EDIT: Wow, a lot of responses. Thanks one and all. And since a lot of people are saying similar things, I will post an global update instead of commenting everyone.
In this case the javascript files are static, hence my curiosity. I have also opened them up and did not see anything attempt to access variables on file load. I've never thought about caching or plain version control, both which seam more likely in this circumstance.
I believe what the author was doing was ensuring that if he creates version 3.3 of his script he can change the version= in the url of the script to ensure that users download the new file instead of running off of the old script cached in their browser.
So in this case it is part of the caching strategy.
My guess is it's so if he publishes a new version of the JavaScript file, he can bump the version in the HTML documents. This will not do anything server-side when requested, but it causes the browser to treat it as a different file, effectively forcing the browser to re-fetch the script and bypass the local cache of the file.
This way, you can set a really high cache time (like a week or a month!) but not sacrifice the ability to update scripts frequently if necessary.
What you have to remember is that this ./js/somefile.js?version=3.2 doesn't have to be a physical file. It can be a page which creates the file on the fly. So you could have it where the request says, "Hey give me version 3 of this js file," and the server side code creates it and writes it to the output stream.
The other option is to force the browser to not cache the file and pull down the new one when it makes the request. Since the URI changed, it will think the file is completely new.
A (well-configured) web server will send static files like JavaScript source code once and tell the web browser to cache that file locally for a certain period of time (could be a day, a week, a month, or longer). When the browser sees another request for that same file, it will just use that version instead of getting new code from the server.
If the URL changes -- for example by adding a query string -- then the browser suspects that its cached version is no good and gets a new one. As such, the ? helps developers say "Oops, I changed this file, make sure the browser gets a new copy."
In this case it's probably being used to ensure the source file isn't cached between versions.
Of course, it could also be used server side to generate the javascript file, without knowing what you have on the other end of the request, it's difficult to be definitive.
BTW, the ?... portion of the url is called the query string.
this is used to guarantee that the browser downloads a new version of the script when available. The version number in the url is incremented each time a new version is deployed so that the browser see it as a different file.
Just because the file extension is .js doesn't mean that the target is an actual .js file. They could set up their web server to pass the requested URL to a script (or literally have a script named somefile.js) and have that interpret the filename and version.
The query string has nothing to do with the javascript. Some server side code is hosting up a different version depending on that querystring it appears.
You should never assume anything about paths in a URL. The extension on a path in a URL doesn't really tell you anything. URLs can be completely dynamic and served by some server side code or can rewritten in web servers dynamically.
Now it is common to add a querystring to urls when loading javascript files to prevent client side caching. If the page updates and references a new version of the script then the page can bust through and cause the client to refresh it's script.