JavaScript Errors caused by a Proxy
The other day the company I work for released a new version of our application. I log onto my computer the morning after the release and see all of the errors reported from the JavaScript. Nothing new, I have thousands of lines of JavaScript, have 3rd party code, and implemented new libraries so there is bound to be some errors. We can not test every single browser configuration out there with our limited test team and developers.
Everyone that works with JavaScript knows that something will slip through when you have such a wide variety of browsers. Outside factors such as Firefox extensions, Ad blockers, popup blockers, and browser plug-ins can screw with your code. I have seen problems with Norton Internet Security (NIS) and also the Firefox extension Adblocker. The Adblocker blocked a tracking script and caused an error to show up on the browser. Not good. Would you have tested that? Does the user have NoScript installed and cut off your JSON requests to outside domains? Is stuff being injected into your responseText? And so on. Only way to know of problems is by user complaints and logging of clientside errors.
I know some of you are saying: "Wait a minute, did you just say you saw JavaScript errors in your server logs?"
If you seen me talk at any of the local user groups or conferences, you than know I track every error in my Ajax applications. The clientside is an alien world! We have no clue what is going on there. If a user with a unique setup comes along and throws an error, we may never know. So I implement error logging so I do know.
If you are interested in logging errors, the basic slides from one of my talks can be found here: www.pascarello.com/presentation/CMAP_ERRORS/Tracking_ClientSide_Errors.ppt. That gives you the very basics of error handling with window.onerror and try/catch. The talk contained all of the little details, the slides were the general info so it is lacking the meat! The slides are basic, but give you a good starting point.
Now back to my topic, so I looked at my error log. To my horror I saw tons of clientside errors. I was about to run out the door since I know the boss would be at my desk asking if I even tested my code. So I open up one error and I see
Browser: Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 3.1)
I open up another and I see
Browser: Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322).
I open up error after error and every one was AOL users. I look at the other information in my log and realize that it is being fired with window.onerror and it is looking for a new object that I added to this release. That had me thinking and I was walking around with my Yo-Yo saying: "I added a new object and AOL users can not see it."
Whenever my co-workers see me with a Yo-Yo, they know I am stressed! I look at the log even more and I realize that it is using my old error handler to log the error.
The light bulb went off and I knew something has cached all of my JavaScript files. It can not be a local proxy since it is not happening to everyone. It only seems to be happening with AOL users so it has to be something with AOL.
AOL uses a proxy which is good and bad for us as developers. If you want to read about it like I did here is all of their information: http://webmaster.info.aol.com/proxyinfo.html. Basically our headers were not set up to expire the way AOL liked so it basically did not check for new files. I have no problem with this since the JS files normally do not change. But when the files do change, we have the issue.
What to do? I know I can sit there and rename all of our files, but I know I am lazy and do not want to have to do this every single time I make a JavaScript change. What we ended up doing is appending a query string value to the JavaScript files. This forces a new lookup when the browser encounters it for the first time. We did it so that this value is obtained from a global variable so can change the variable and all of the JS files will change. As soon as we released the patch, AOL errors disappeared from the logs.
So now we get the benefit of our files being cached on the user's machines and other proxies along with the ability to send out updates without worrying about the expired headers. Hopefully this will help others out there when you are dealing with a lot of JavaScript!
Eric Pascarello
Coauthor of Ajax In Action
Moderator of HTML/JavaScript at www.JavaRanch.com
Author of: JavaScript: Your Visual Blueprint for building Dynamic Web Pages