4

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.

Wesley
  • 32,320
  • 9
  • 80
  • 116
S.Kiers
  • 161
  • 5
  • 1
    First of all, no. The first stable release of .NET 4.0 is not even 2 years old, so it hasn't been running "for multiple years". Second, try enabling [Failed Request Tracing](http://learn.iis.net/page.aspx/266/troubleshooting-failed-requests-using-tracing-in-iis/) to get a better understanding of what is happening – Mathias R. Jessen Jan 16 '12 at 01:57
  • Actually, you are right. The app has been operational for 10+ years, but it certainly hasn't been on 4 that long (or even .Net that whole time) :) I will pass on this comment to our senior dev and see what he thinks. – S.Kiers Jan 16 '12 at 23:03
  • Isn't Failed Request Tracing an IIS7 thing only? – S.Kiers Jan 16 '12 at 23:05
  • The feature is, the [concept](http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/5f5bd256-7d1f-4239-9a7f-8eea4072fcb3.mspx?mfr=true) is not :-) – Mathias R. Jessen Jan 16 '12 at 23:18

1 Answers1

2

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."

Community
  • 1
S.Kiers
  • 161
  • 5