IE8, favicon.ico and silly server stunts

At first glance, load testing software seems like it should be pretty straightforward. And like most things, it turns out to be really complex — at least, if you want to do it well. Simulating a browser could be pretty easy – except for the need to do it very, very, very efficiently, so that the solution can scale to simulate hundreds or thousands of  virtual users per computer.

What does this have to do with favicon.ico and IE8? Occasionally while helping a customer use Load Tester, we run into some behavior that is difficult to explain, and this was one of those weeks. A customer reported a problem that indicated the virtual user was loosing its session at some point during the execution of the test scenario. While investigating the problem, two of our test engineers noticed that the testcase contained multiple requests for favicon.ico and the server was were returning a forward to the login page. In itself, this did not seem like a problem – until they noticed that this response was resetting the session cookie that had just been set when the user arrived at the login page in the browser. This is a little hairy – so bear with me while I try to simplify what was happening:

  1. The testcase starts with the user visiting the website. The server is configured to send all unauthenticated requests to the login page, so the first response forwards the user to the login page, which clears any existing session cookies.
  2. There is a simultaneous favicon.ico request, which is also forwarded to the login page. Since this response is not an icon, the browser ignores it – it will request it again later.
  3. The user successfully logs into the system and starts proceeding through the test scenario.
  4. Later in the testcase, another favicon request appears – as well as a subsequent request for the login page. This  results in clearing of the session cookie again – invalidating the login and causing the next page request in the testcase to receive an unexpected result (a foward to the login page).

Our analysis thus far has turned up these interesting facts about the web application:

Interesting fact #1 – The server requires authentication for all resources, including images. When this happens before the login, all of those resource requests will receive the same response – a forward to the login page.

Interesting fact #2 – The login page invalidates the current session (by clearing the existing session cookie) without first checking to see if the existing session is valid. Simply visiting the login page ends the users session.

We have also turned up one puzzling question:

Puzzling question #1 – We understand why the first favicon.ico request in the testcase recording resulted in a forward, but why did the subsequent requests fail as well?  They should have succeeded, since the user is logged in at that time.

Now at this point, we are able to give the user a choice of workarounds so they could move forward with their load testing. Option number one is to remove the favicon.ico requests (and the subsequent login page requsts) from the testcase.  This will prevent the session cookie from being cleared and allow the testcase to complete as expected. However, it will also not send the server as many requests for those resources – thus altering the load profile slightly. Perhaps the better option, number two, is to move those resources to the beginning of the testcase, before the authentication occurs. Moving them to the front will change the distribution slightly, but when hundreds of users are running, the net effect (in terms of the average number of requests/sec) will be negligible.

We were not satisfied with that solution, however, so we kept digging. Subsequent research uncovered another interesting fact:

Interesting fact #3 – When browsing the site with IE8, the site icon (favicon.ico) does not show up – even after the user has authenticated. When browsing the site with IE7 or Firefox, the site icon does appear correctly.

This leads to our next puzzling question:

Puzzling question #2 – Since the original recording of the testcase was made with IE8, we know that the requests for favicon.ico were made by IE8 – why did those requests fail for IE8 but not for IE7 and Firefox?

Some research into IE8 gave us one working theory:

Perhaps the change in behavior from IE7 to IE8 was related to the IE8 security enhancements. IE8 runs each tab as a separate user session – isolating each tab from each other. It is possible that the main frame of the application, including the URL bar, is a separate user session as well. If so, and this separate frame requests the site icon (favicon.ico) to display in the URL bar, then because it is running as a separate user session, it would not get the session cookie resulting from a successful user login.

So from this, we get a theory that could explain our two puzzling questions:

Theory #1 – If a server requires authentication for EVERY resource, including favicon.ico, the browser will NEVER be able to successfully fetch the site icon in IE8. When the server returns a 404 for favicon.ico, the browser will stop requesting it. But if it receives a forward to a web page (such as a login page), IE8 will continue requesting favicon.ico indefinitely – resulting in unnecessary traffic to/from the server.

It is worth noting that in many cases, this particular server configuration problem may not be limited to favicon.ico. In the case of this customer, it applied to every resource requested prior to the login. CSS files, javascript files, images – everything was returning a forward to the login page. As a result, the login page was actually being sent from the server dozens of times per user.

And now I”m ready tie this back into my opening thought about the complexity of load testing software (finally getting to the point!). In order to properly simulate this specific scenario, a load testing tool should probably simulate two separate user sessions and put requests made from the browser’s URL bar into a separate session…at least for IE8. I’m not aware of any testing tool that can do this. If the browser behavior we offered above turns out to be accurate, then load testing tools will need to account for this.

Happy testing!

Chris, Chief Engineer

Add Your Comment

You must be logged in to post a comment.


Copyright © 2020 Web Performance, Inc.

A Durham web design company


(1) 919-845-7601 9AM-5PM EST

Just complete this form and we will get back to you as soon as possible with a quote. Please note: Technical support questions should be posted to our online support system.

About You
What you Need