The result column in HttpWatch may sometimes display the value (Aborted) instead of an HTTP status code:

(Aborted) is one of three pseudo status codes that are used in HttpWatch to display information about HTTP requests that did not receive a status code from the server:

• (Aborted)
• (Cache)
• ERROR_*

The last two values are fairly straight forward. The (Cache) result is displayed when content is read directly from the browser cache with no network round-trip. If there’s no network round-trip, there’s no HTTP status code returned from the server. And the ERROR_* result (e.g.  ERROR_INVALID_URL) is used when a request fails to complete because an error was detected by Internet Explorer.

The (Aborted) value is more complex in its origin. It occurs when IE has started to process the request for a URL (e.g. to download an image), but then decides to cancel the operation. Here are some examples of when this can occur:

1. If you click on a link or bookmark while a page is downloading, or click on IE’s Stop button, you will see that IE cancels any requests which are still active and HttpWatch shows the (Aborted) result.
2. A CSS rollover image on a page will start a request when the mouse pointer is moved into its active area. If the mouse pointer quickly moves away again, IE may abort the request if it has not already completed.
3. Sometimes javascript is used to fire off requests for background tasks or to gather statistics on a page. Often this can lead to aborted results if the javascript does not wait for the response to be received from the server.

A common question is “Will our server receive requests that ended up being aborted?”. The answer is that it depends when the request was aborted. By looking at the timing chart in HttpWatch you can determine how far the request was through its normally processing cycle before it was cancelled.

Here’s an example of a request that was aborted while a connection was being made:

The server would not have received the HTTP request message in this case, because the Send state was not reached.

The request shown below was aborted when IE was awaiting a response and therefore the request would have been delivered to the server:

The presence of an (Aborted) entry in an HttpWatch log file is often just a consequence of the way that the user is interacting with a web site, rather than an indication that something has gone wrong.

Some customers contacted us recently to ask why they were seeing http://:/ recorded in HttpWatch. This URL produces an ‘Error 0x57’ in IE 6 and ERROR_INTERNET_INVALID_URL on IE 7.

The sites causing these errors had one thing in common. They were either using the jQuery or YUI javascript libraries. It was not immediately obvious where this URL was being generated because there was nothing in the DOM with that URL when we checked with the IE Developer Toolbar.

We set up a simple test page using the commented version of the jQuery library. If you access this page using HttpWatch you will see http://:/ being recorded as the page is loaded:

Then we searched for //:  guessing that IE was adding the http: prefix and the trailing forward slash.  HttpWatch highlighted the following piece of code in jquery.js. It is used on IE to generate an event that is equivalent to Firefox’s DOMContentLoaded:

The jQuery library avoids using the standard window.onload event because it doesn’t fire until the page and all its images have been completely downloaded. This can lead to significant delays in providing javascript based functionality on a page. The advantage of using the DOMContentLoaded event is that it fires as soon as the page’s DOM elements can be safely accessed from javascript.

The workaround for the lack of the DOMContentLoaded event in IE uses a temporary <script> block to generate an event. However, the onreadystatechanged event of the <script> block will only fire at the correct time if the defer attribute is used and the script block has a src attribute. The value used in the src attribute causes the invalid URL that was recorded in HttpWatch.

The temporary <script> block is deleted when the event is triggered leaving no trace in the page’s DOM.

A similar workaround for IE is used in the YUI library:

You can see the resulting http://:/ if you go to the YUI Event Example:

The //: value in the src attribute is a compromise solution. If it contained a real URL it would trigger an extra network round-trip. The invalid URL used does cause the error seen in HttpWatch but the effect on performance if minimal. In the YUI Event Example shown above it only adds 3 milliseconds to the download time of the whole page.

Typing Ctrl+F5 in Internet Explorer is a handy way to force the reload of a page and all its component parts (e.g. images, css , javascript etc). It has the same effect as visiting a page with an empty browser cache.

If you use HttpWatch with Ctrl+F5 in IE 6, you can see that every request returns an HTTP 200 OK response:

This indicates that the complete content of each HTTP item was returned.

However, in IE7 you may see a different response after typing Ctrl+F5:

Only the HTML of the page is returned with a 200 OK response; the other items return a 304 Not Modified response. Looking more closely with HttpWatch you can see that If-Modified headers were sent with every request. This is what you would expect from typing F5 or clicking the Refresh button.

It turns out that Ctrl+F5 only works in IE 7 if the keyboard focus is on the web page itself. If you move the focus anywhere else, such as back to the location bar, it ignores the Ctrl key and behaves as if F5 were typed on its own.

So if you really want to do a forced refresh in IE7 make sure you click on the web page or tab first.