Usability, MVC, ASP.NET

24. Januar 2012 11:08
by Henrik Stenbæk
1 Kommentare

ASP.NET 4.0 acting strange when User-Agent equals Safari 5.1

24. Januar 2012 11:08 by Henrik Stenbæk | 1 Kommentare

During the last couple of days I have spend my working hours trying to resolve a strange problem on one of our production sites. I used a lot of time trying to figure out what coursed the problems and searched the web without any result. As part of the troubleshooting I also prepared a question for It turned out when I started to post the question that stackoverflow was able to suggest a question with similar content and that this other question contained the answer – it has been the all the time but I wasn’t able to find it because I have googled the wrong keywords. In the hope that this could help other people that is googling with the wrong keywords I herby post the text that original prepared for stackoverflow (including a link to the correct answer).

“We have a website running on ASP.NET 4.0 Webforms (IIS 7). The site has been online for years (since 2008) running under ASP.NET 2.0. Recently (like October 2011) we lifted it to 4.0, and after that we have started to get complaints from Safari 5.x users that they can’t sign in to the site, but keep on getting redirected to the login page.

The site is running in a farm with four servers. When the problem occurs it’s not on all 4 servers at once. When a node starts redirecting the user, the situation will persist for an unknown amount of time and then the node will return to normal – we haven’t yet discovered how long this amount of time is, it could be equal to app pool recycling. After all we have experienced that recycling the app pole seems to solve the problem.

We have experienced that when we hit one of the servers that is “infected” with the problem, we don’t really need to use a native Safari 5.x browser. All browsers that is showing the Safari User-Agent is redirected. The problem exists when User-Agent is:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.50 (KHTML, like Gecko) Version/5.1 Safari/534.50

If we spoof a Chrome or Firefox to display this User-Agent the problem will occur. 

If the same browsers are showing their native User-Agent they have no problem in signing in and browsing the site. As if we spoof a Chrome or Firefox to display an older Safari User-Agent: 

Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_4_11; nl-nl) AppleWebKit/533.16 (KHTML, like Gecko) Version/4.1 Safari/533.16

they have no problem browsing the site.

The fact that any browser that impersonates as Safari 5.1 does experience the problem, have lead us to the conclusion that it is a 100% server related problem.

For some reason the server will decide that a Safari 5.1 browser is not suitable to browse the site as a logged in user and issue a 302 redirect to the login page.

This led us to look at the safari.browser file. When digging into this file it seems that there is no entry taking care of Safari browsers after version 4. We haven’t been able to verify this. But we can see that browsing the site with any of the above “User-Agents” results in different results when looking at System.Web.HttpBrowserCapabilities

The Safari 4.1 header returns

  • Platform = MacPPC
  • JavaScript Version = 1.7

The Safari 5.1 header returns

  • Platform = Unknown
  • JavaScript Version = 1.6

But if the problem is related to a missing entry in safari.browser why isn’t the problem persistent?

Could it be that if ASP.NET couldn’t recognize the browser it won’t bother checking the credentials cookie?

Does anybody have had any experience like this and have you solved it?”

Some of the words I used wend googling includes:

  • "safari.browser"
  • safari.browser file asp net
  • Request.Browser.Adapters renders
  • ASP.NET 4.0 keep on getting redirected to the login page

I searched stackoverflow for 

  • safari iis
  • CONFIG Browsers

The correct search is something like

  • applewebkit .net 4 user-agents

because it will lead one to the correct answer:

It seems that I have found the root cause of the problem. The UserAgent -> BrowserCaps resolving mechanism uses a cache to temporarily store mappings. Unfortunately it uses (by default) the first 64 characters of the UserAgent string as cache key and THAT is just BS... Occasionally a user agent pops up that looks like a Safari, but really isn't and that one is not resolved properly (Mozilla 0.0), but the mapping is still stored in the cache, which means that all UserAgent strings with the same 64 character prefix are now incorrectly mapped as well until that cache entry expires (sliding window with 1 minute). The key length used for caching can fortunately be configured with

<browserCaps userAgentCacheKeyLength="..." />

in the config section. I've upped the key length to 256 and since that the problem has disappeared..”