On what basis does javascript files get cached? Say I load a file with the name 'm-script.js' from one site and on another website I use the same name 'm-script.js' but with different contents. Will the browser fetch the new one, or just look at the name and load it from the cache? The urls for both the m-script.js file are different (obviously).
Thanks.
If the url is different the cached copy will not be used. A new request will be made and the new file will be downloaded.
There would be a huge security and usability issue with the browser if a Javascript file cached from one website was used on another.
Browsers cache files by their full URI.
This thread( How to force browser to reload cached CSS/JS files? ) will help you to understand.
Since nobody has mentioned it yet, there is a lot more involved in HTTP caching than just the URI. There are various headers that control the process, e.g. Cache-Control, Expires, ETag, Vary, and so on. Requesting a different URI is always guaranteed to fetch a new copy, but these headers give more control over how requests to the potentially-cached resource are issued (or not issued, or issued but receive back a 304 Not Modified, or...).
Here is a detailed document describing the process. You can also google things like "caching expires" or "caching etag" for some more specific resources.
Related
I understand how to use version numbers and force the download of updated files on my own website but what can be done under this circumstance.....
I have some small scripts i've written for public use , and i have about 200 different websites who link my js file on their website. When i make an update to the file , i have to get them all to manually change the version number of the file so they and their users are re downloading the latest update.
Is there anything i can do on my server , the host , that can force the other sites to redownload latest version without anything manual on their end of things ?
There are 2 persistent problems in computing: Cache invalidation, naming things, and off-by-one errors.
If you want clients to get new versions of a file without changing the name of the file then you simply have to lower the max-age you set in the caching headers so that they check more frequently and get the new version in a reasonable period of time.
That's it. End of list.
You can somewhat mitigate the effects of the increased request load by also implementing an ETag header that the client will send back on subsequent requests and can be used to detect if the resource is unchanged and optionally serve a 304 Not modified response.
However, depending on the cost of implementing and running ETag checks you might just want to re-serve the existing resource and be done with it.
Or use a CDN which should handle all the ETag nonsense for you.
I am writing a social media engine using Javascript and PHP, with flat files as my main information transfer tool. When my program adds to text files that are over a day old, they will not show up when requested by an AJAX program, until they are accessed directly by a URL and refreshed twice. Is there a way to prevent this from happening? Please do not suggest the use of a database.
The most likely reason to why you need to access the flat files directly by URL and refresh twice is that your browser is caching them. Refreshing updates the browser's cache with the latest version.
When a web server is serving static content it tells the web browser to cache the content for quite a while since the content being static is unlikely to change for some time.
When a web server is serving dynamic content that almost always means that the content is going to change very fast and that it might be a bad idea to cache it.
Now the reason to why you shouldn't access your flat files directly with AJAX is not because of the cache issue (although it does resolve the issue) but because of security. What happens if you have some secret information in the file? Sure you can tell the browser not to fetch that part but the user still will have full access (by URL) to the file.
The same way you don't let the browser access your database you don't let the browser access your flat files directly. This also means that they should be stored outside the document root or protected from public access by other means.
I have a really simple site that I created. I am trying to test JS caching in the browser but it doesn't seem to be working. I thought that most major browsers cached your JS file by default as long as the file name doesn't change. I have the site running in IIS 7 locally.
For my test I have a simple JS file that is doing a document write on body load. If I make a change to the JS file (change the text the document write is writing), then save the file, I see that updated when refreshing the browser. Why is this? Shouldn't I see the original output as long as the JS file name hasn't changed?
Here is the simple site I created to test.
When you refresh your browser, the browser sends a request to the server for all the resources required to display the page. If the browser has a cached version of any of the required resources, it may send an If-Modified-Since header in the request for that resource. When a server receives this header, rather than just serving up the resource, it compares the modified time of the resource to the time submitted in the If-Modified-Since header. If the resource has changed, the server will send back the resource as usual with a 200 status. But, if the resource has not changed, the server will reply with a status 304 (Not Modified), and the browser will use its cached version.
In your case, the modified date has changed, so the browser sends the new version.
The best way to test caching in your browser would probably be to use fiddler and monitor requests and responses while you navigate your site. Avoid using the refresh button in your testing as that frequently causes the browser to request fresh copies of all resources (ie, omitting the If-Modified-Since header).
Edit: The above may be an over-simplification of what's going on. Surely a web search will yield plenty of in-depth articles that can provide a deeper understanding of how browser caching works in each browser.
Does it send an HTTP GET request for the specified file? I'm trying to write my own NodeJS webserver, and want to know how to go about dealing with sending the browser the javascript files it needs.
Let's say I'm using several javascript libraries for a web-app I'm building, and for each of them I have a script tag in the head of my HTML file (e.g. <script type="text/javascript" src="jquery.js"></script>). In my server, would I be able to code something up to call different functions based off of the src requested, and to return a file that isn't necessarily in the same location that the HTML would make one expect it to be?
I'm still new to NodeJS and webservers in general, so I apologize if this is really obvious to other people out there...
Does it send an HTTP GET request for the specified file?
Yes.
I'm trying to write my own NodeJS webserver, and want to know how to go about dealing with sending the browser the javascript files it needs.
Then don't worry about how the browser decides what HTTP requests to make. Just implement the HTTP specification.
In my server, would I be able to code something up to call different functions based off of the src requested, and to return a file that isn't necessarily in the same location that the HTML would make one expect it to be?
This sounds like you are planning to serve up different content for the same URI based on the referer header … I'd expect this to hit a cache and turn into a race condition based nightmare. Don't do it. Write your HTML so if you need different scripts, you request them from different URIs.
If, on the other hand, you mean that you want to return data without reading it out of a file on the file system, then that is fine. Clients don't care how the server determined what data to put in an HTTP response. Just make sure that it is sane and consistent.
Does it send an HTTP GET request for the specified file?
Yes.
You don't have to worry about when and how the resources are requested from the browser, just map the resource addresses that you want to make available to the content that you want to return for each resource.
would I be able to code something up to call different functions based off of the src requested, and to return a file that isn't necessarily in the same location that the HTML would make one expect it to be?
Of course. There is no direct relation between the address of a resource and the physical file where you get the data for the resource, there is always some code that does the mapping between the resource address and where the data is fetched. It's just easier to manage resources when the files are arranged in basically the same hierarchy as the resource addresses.
Does it send an HTTP GET request for the specified file?
As Quentin said, Yes the browser will request each script file specified in the source HTML with a GET request for that particular URI.
When your web server receives that GET request, you can do anything you want to return data for the URI request. You do not have to actually return a file from that path. In fact, you can parse out the path and use the different parts of the path as data parameters in the request (that's what a lot of web apps do these days).
So, if the request comes in for http://www.mysite.com/user/john/accountnumber, you could look up in your database and fetch the account number for a user named "john" and return that data. The result does not have to come from an actual file or from anything that actually has that path.
A web app I'm developing uses lots of asynchronously loaded images that are often modified over time while their URLs are preserved. There are several problems with this:
If I do not provide the images with caching explicitly disabled in HTTP headers, the user will often receive an out of date image version, but doing so substantially increases server load.
How can I take the cache control away from the browser and manually evaluate if I should use the cached image or reload it from the server?
Since there are many separate images to be loaded, I also parallelize image downloads over different hostnames (i.e. the image01.example.com, image02.example.com, but all these hostnames resolve to the same physical server). Since the NN of the hostname is generated randomly, I also get cache misses where I could have retrieved the up-to-date image from the browser cache. Should I abandon this practice and replace it with something else?
What cache control techniques and further reading material would you recommend to use?
To force a load, add a nonsense parameter to the URL
<img src='http://whatever/foo.png?x=random'>
where "random" would be something like a millisecond timestamp. Now, if what you want is to have the image be reloaded only if it's changed, then you have to make sure your server is setting up "Etag" values for the images, and that it's using appropriate expiration and "if modified since" headers. Ultimately you can't take the cache control away from the browser in any way other than your HTTP headers.
Instead of generating NN randomly, generate it from a hash of the image name. That way the same image name will always map to the same hostname, and you'll still have images distributed across them.
I don't have a good suggestion but web implementation advice is abundant on the Internet, so I'd say start with Google.