Detecting Response status code through JavaScript

Is there a way of finding out the status code of the content of an IFRAME to find out if it was dished out by the server or out of the browser cache using JavaScript?
Whenever I Google this I only get stuff back about Ajax but I'm not making an out and call.
Who is Participating?
hieloConnect With a Mentor Commented:
I know it is lengthy, but I think I answer your questions and possibly solve your problem.

The 404 error code simply means that the page/resource your requested was not found by the server. However, it does not necessarily mean that you cannot send javascript. Like I said before, when the page you request is not found, the server sends you a different page which normally informs you of the fact that the page does not exist. In all the web servers that I have configured, there is an option/setting that tells you which file it is and where it is located on the system. You could customize that file so that instead of it being an old boring page, the error message appears within your site's template (if any). For example, look at
That is a custom 404 error page which sends javascript to the client. You could create your own custom 404 and/or 500 error pages with a javascript statement that as soon as the page loads it can call a specific function that you know will exist on all your site. As soon as that function gets executed you will know that the requested resource does not exist. I am 99.99999999% sure that with the custom error page, using any webserver, you can inform the user which resource was being requested but not found. For example, if you look at, if they wanted, via javascript could extract the name of the requested resouces and use it to as the argument to some site-wide error handler.

The cache is a different monster altogether. The http status codes(200, 300, 400,etc) are sent to the client by the server whenever there is communication/interaction between the two. If your browser retrieves the page from cache, you will never see a 200, 400, or 500. Maybe a 304 error. If the browser can establish a communication with the server, the browser basically says to the server:
"send me the following file: 'filename", but only if it is newer than the following date: 'date of cached file'." This is known as a "conditioal GET request".  If the file exists on the server but has the same timestamp as the one that the client holds, no data (meaning HTML) is sent to the client, just a mere status code: 304. When the client sees this, it knows that it has the most recent copy stored on cache and will load the iframe or browser from whatever it has in the cache. In the case where it had the file in cache but was not able to establish a connectio (regardless of whether the client system's network is down or the remote server is down), the client (browser) is unable to establish a connection and simply load onto the browser the copy of the file that it has on cache. If you are interested, the meaning of the codes are here:

To avoid the cache altogether you can "instruct" the browse not to cache your info. Browsers are not obliged to follow said recommendation, but most do. In my experience, I get better results when:
1. Include the following on the html code (NOTE: the meta tags should go within the head before any other tags, including title)

2. Send an http header from the server. For example, in ASP  this can be accomplished as such:
Response.CacheControl = "no-cache";
Response.AddHeader( "Pragma", "no-cache");
Response.Expires = -1;
Whatever your server, it will have an equivalent feature.

How can I tell if the page I requested is cached or not?
Simple: Make sure that in all your pages you include the current system time in UTC format. You could just include it in some meta tag if you do not want it visible. Then, you would also need some javascript to create a system date object and covert it to UTC format. If the difference between the javacript generated UTC time and the one stored in the meta tag is significant, you got a cached page. The difference should typically be a few seconds. The reason for UTC date is because the server may reside in UK, but you may reside in the US. The different timezones will drive you crazy. It is simpler in UTC time because it is like saying, if the whole world synchronized their watches, this is what time it would be right now everywhere!
This is an issue I looked into not too long I ago. I could not figure this out the status code, but what I found is that some browsers fireup the onload event when the frame finishes loading. Thus, you could create an onload event handler. However, even if you do not get a 200 code, like 404(File Not Found) or a 500-(Server Error), the onload event still triggers. The work around would be for the page that you are loading to have a script snippet at the end and once it loads it can call the function originally intended to be the event handler.
Silas2Author Commented:
Could I put an OnLoad event handler into the IFRAME, and somehow capture the response status for the IFRAME only?
Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

You will have the same problem. You must realize that whether the status is 200, 404, or 500, the communication is the same:
client requests resource; server finds resource; server sends resource;
However in the case of a 404, the resource sent is not the resource asked for. The server is nice enough to no "leave you hanging" and instead it sends you an alternate resource, the 404 error page. The same principle the 500 page.
Basically triggering the onload status is like saying, 'the server has finished sending me some resource after I requested a resource'. The whole point of the status code if for the client to determine easily if the resource asked for is the one sent by the server.
Silas2Author Commented:
Are you saying that if the response is a 404 error page, I am not going to get any JavaScript anyway as the error page doesn't contain my JavaScript?
I'm really only interested in finding out whether my IFRAME is populated from the browser cache or from the server, can you think of anyway of doing that?
Silas2Author Commented:
I think you're right, anyway I realise really it's the age of the data which is impoortant to the user rather than whether   It was dished out by the browser cache or from  the server.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.