views:

41

answers:

3

My web application sends me diagnostic info from the browser javascript telling me that a [script] tag I've injected has failed to download the associated .js file. I can't reproduce this locally, and there is no particular pattern to which file fails, or what the browser type is. There is a pattern to the geo location of the requests - Mexico and Brazil are always more frequent - so I'm guessing that perhaps the internet in general is just more flaky there, and it is just network issues causing the failures.

I'd really like to know for sure, though. Is there any way to determine, from the browser javascript, whether the failure occurred because of an error returned by the server, from a network error, or from a protocol timeout? I don't care if the mechanism is browser-specific, since it seems likely that the same issue is causing the error on all browser types.

+1  A: 

I doubt it: The <script> tag may have an onerror event like images do, but I doubt you are going to get any detailed information from it.

The only thing I know in JavaScript that gives detailed error info like what you are looking for is Ajax. In Ajax, you can catch timeouts as well as server response codes.

You could either try making an Ajax request to the script file when the "normal" inclusion fails, and analyze that request for errors. I'm not entirely sure, though, whether that'll help: It could be that the <script> part fails, but the Ajax call loads just fine, because of the infrequent nature of the failures.

The second option - and I don't know whether there is a stable implementation for this - is actually loading the script using Ajax, and injecting it into the document. I'm sure some sick creative mind has dabbled with this already somewhere :) This would give you the opportunity to analyze any failures (e.g. make another Ajax call, sending diagnostic information).

Last not least, take a look into your server's error logs for any unusual occurrences.

Pekka
I'll see if there is anything we can do with ajax; I'm a little concerned about using it to actually download the script - seems like that might subvert some of the built-in script download handling the browser does - but we could at least try it in test.We might add retries when we detect these errors, but I worry that since we see a lot of these script download errors, perhaps our other downloads are also failing, but just not getting logged.Good point about the server - I'll check with the guys who run our resource servers and see if they've observed any of these on their end.
Bruce
+1  A: 

First off, as a veteran of the ISP industry, I can tell you that South of the USA the communications infrastructure rapidly deteriorates; just consider that it's mostly 3rd-world countries with ancient copper-based longhaul telephony networks.

an error returned by the server

Use server logs to detect these! You shouldn't need to ask the client (browser) something which you should already know the answer to.

from a network error, or from a protocol timeout?

Since a network error is pretty broad (e.g. a protocol timeout is a network error), I'll address that, and no, there is no way to debug these unless you use some AJAX. jQuery has a jQuery.getScript() specifically for this task, but it likely won't give you the options that you need, so you'll need to take their jQuery.ajax() example implementation of jQuery.getScript() and then implement the error() method where you can peek into the XHR to see what the failure reason was. Of course jQuery isn't required for all of this, it just makes it much easier.

ken
A: 

The <script> tag has onerror but as Pekka said before it may not provide any useful feedback. Here a code snippet just in case its something you'd like to explore further:

var url = 'test.js';
document.write('<script src="'+url+'" type="text/javascript" charset="utf-8" onerror="throw(\'An error occured: \' + this.src)"><\/script>');
michael