Internet Explorer Restart and the ClientAbortException

Posted by Chris Bryer on 9 October 2014 | Comments

Tags: , ,

A little over a year ago I was working on a large enterprise web application and we decided to refactor the system's cache buster.  At the time, whenever we pushed a new version of the app to development, QA, UAT and production environments users would have to clear their cache, otherwise they would risk using a chached version of the javascript files, leading to errors.

We decided to follow the Spring framework's recommendation of changing the url path to the resources each time we pushed a new release, and we ended up injecting the applications version number (pulled from the POM file) into the url. This forced the browser to download new resource files (.js, .css, etc) after an update from an uncached source and was a very dependable solution to cache busting.  Our paths changed from

www.mysite.com/resources/js/file.js

to

www.mysite.com/resources/1.3.1-Release/js/file.js

The files did not physically change location on the server (they always remained at /resources/js/file.js), so we needed to route the requests through the servlet context so we could dynamically map the requested path to the actual file.

This approach worked great, and people were happy.  Then we started seeing ClientAbortExceptions in our logs, without any error reports from users.  ClientAbortExceptions are thrown from tomcat when a http request is terminated by the client while the response is being sent to the client.  An even bigger problem for me was that my internet searches revealed that very few people experienced this exception and nobody had a solution for it.

After rolling up my sleeves and investigating the problem further, I eventually found some patterns:

  1. Only occurred while using internet explorer (of course, right?)
  2. The exception was never thrown when a page was loaded with a fresh cache, but would always happen after.
  3. I noticed in the logs that many exceptions were thrown in a row
  4. Analyzing network activity with internet explorer's F12 developer tools, I saw several 'Aborted' results from css and javascript files, then the files would be loaded again shortly after with 200 response codes.

This started feeling like a client side problem instead of a server side problem, and after searching a little more about this behavior, i found one msdn blog post, describing why Internet Explorer aborts and restarts connections.

In short, what resolved the exception was to change the order of the meta tags in my head section, something i never thought would affect a web page's performance.  The optimal order of html tags is:

<doctype>
    <html>
        <head>
        <meta http-equiv content-type charset>
        <meta http-equiv x-ua-compatible>
        <base>
        <title, favicon, comments, script blocks, etc>
        ...

Keep these meta tags in the beginning of the <head> tag.  Apparently in modern versions of internet explorer they need to be in the first 4kb of the page, otherwise they are ignored.  After making the changes, i noticed the exceptions in our log files started disappearing, as well as other IE warnings that I've overlooked in the past (HTML1115, HTML1113 warnings).