Home / server / Questions / 350150
Accepted
S.Kiers
Asked: 2012-01-16 15:05:22 +0800 CST

IIS6 Website 'breaks' when viewed using Safari Browser

  • 772

I have an application that is using ASP.NET 4.0 Webforms on IIS 6.0 that has been operational for multiple years. A recent deployment to the app has caused some very random (to us) intermittent issues in the Safari browser (not any other browser).

After a server reboot the application seems to work fine for periods of time, but then it will 'break'.

It is 100% server level, as it works find on all computers until it 'breaks'. Once broken, it is broken across every computer running that exact version of Safari. It you change the Safari version, or switch between http and https it will work again, until that version 'breaks'

It seems that the breaking is linked to the headers sent to the server.

Once 'broken' it has issues with CSS being applied to ASP.NET controls, the addhistory method throws javascript errors because it cannot find the __dopostback function.

asp.net iis-6 safari

1 Answers

  1. Best Answer

    Answer found at : https://stackoverflow.com/questions/5478181/net-4-0-website-cannot-identify-some-applewebkit-based-browsers

    "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. Now I'll try to figure out which UserAgent string was responsible for the cache poisoning in the firs place - and I'll update this post if I find anything."

    • 2