After upgrading a site to asp.net 4.0 on IIS6, we discovered that some Safari browsers started having problems---occasionally. I've traced this down to an incorrect browser detection in Asp.net's HttpBrowserCapabilities. It is sometimes detecting safari browsers as "mozilla" with EcmaScriptVersion==0.0. Frustratingly, this is coming and going---sometimes it works and sometimes it doesn't. A browser with a particular User-Agent will work for a while, stop working for a while, then work again for a while.

An example of a User Agent that doesn't work (usually) is this: "User Agent=Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-us) AppleWebKit/534.52.7 (KHTML, like Gecko) Version/5.0.6 Safari/533.22.2"

Annoyingly, browser detection works correctly on all our non-production servers. I compared the Config/Browsers/*.browser files on the different servers and they are identical.

Thinking the configuration might just be cached somewhere in the asp.net framework, I also ran "aspnet_regbrowsers.exe -i" from the 4.0 installation. This doesn't have any effect.

This seems to happen regardless if a browser has had its cache refreshed---even browsers that have never seen the site before have this problem.

I've also restarted IIS a few times. Short of rebooting, I can't think of anything else to try.

Any idea what might be causing this?

EDIT: Jan 19/2012

I've spent several days trying to isolate this problem unsuccessfully; it looks to me like maybe it has something to do with the Application Pool, because some application pools were returning the correct value, but some do not. When I move a buggy webapp from one app pool to another it sometimes temporarily works, until the next day when it doesn't work any longer. My guess is that the pool has some threads which are corrupt, but I can't seem to clean them up. This intermittent problem survives recycling the pool, stopping and restarting iis, and rebooting the system.

If you go to http://www.industrymailout.com/Industry/Capability.aspx with Safari, you can see that UserAgents will show up as "Browser=Mozilla", when it should say "Browser=Safari". However, an identically-configured virtual app which is pointing to the same directory (http://www.mymailout.net/Industry/Capability.aspx) will work correctly.

With the safari developer menu enabled (on windows), I can change the useragent to "Safari 5.1 - Mac" and it detects the browser incorrectly. But "Safari 5.1 - Windows" is detected correctly.

I set up a VM with Server2003 and IIS6 on it to test it, imported all my IIS6 settings and it works fine there.

I'm about to start reinstalling everything from scratch on a new machine with IIS7---I don't know what else I can do.

  • Two questions: First, are all windows updates applied to your IIS 6 server? Second, and more important, are your non-production servers also IIS 6?
    – NotMe
    Dec 10, 2011 at 0:09
  • Yes, all updates are there---which update applies to this situation? I have no other IIS6 machines to test on, but this seems like an Asp.Net configuration issue to me. Are you aware of an IIS6 vs IIS7 issue?
    – mikebridge
    Dec 11, 2011 at 2:41
  • It's been my experience that the only proper way to test anything prior to pushing to production is if all of the machines have the exact same configuration. There were massive changes in II6 vs II7; so I wouldn't trust that a site functions the same when deployed on both.
    – NotMe
    Dec 12, 2011 at 15:09
  • Thanks for the general advice, but I have set up a VM with a Server2003/IIS6 environment to see if I could isolate the problem there but it appears to be only on the production server. It looks like a problem with IIS6 corruption rather than an IIS6/IIS7 config issue.
    – mikebridge
    Jan 19, 2012 at 18:15

1 Answer 1


This appears to be the solution:


Essentially the browser cache is being populated incorrectly, since the UserAgent is being truncated at 64 bytes.

After setting this in Web.config it is working correctly for me in all versions of Safari:

<browserCaps userAgentCacheKeyLength="256" />

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .