Home > Uncategorized > ASP.NET 4 BrowserCaps (or: what were they thinking?)

ASP.NET 4 BrowserCaps (or: what were they thinking?)

I have recently run into a very peculiar problem: After the switch to .NET 4, our company website started reporting strange errors. The exception message reads as follows

The page is performing an async postback but the ScriptManager.SupportsPartialRendering property is set to false. Ensure that the property is set to true during an async postback.

And even weirder is that after some investigation and adding some debug information to the exception log it became clear that all those exceptions were “caused” by Safari UserAgent strings (iPhone, iPad, …) that according to the ASP.NET browser capabilities were “recognized” as “Mozilla 0.0″ Browsers with basically no capabilities whatsoever.

The first WTF is that the .NET framework actually throws an exception if it detects an async postback from a browser that according to BrowserCaps does not support async postback. It’s as if they think they know best who is capable of async postbacks even with overwhelming evidence to the contrary…

The next WTF was substantially harder to find. Why are Safari UserAgents occasionally recognized as Mozilla 0.0 and why was I never able to reproduce the issue even when using a UserAgent string that I just copied from an exception?

The answer lies in

<browserCaps userAgentCacheKeyLength="64" />

The default setting for the user agent cache key length is to take the first 64 characters of the UserAgent string. This might have been a reasonable default 10 years ago, but seriously? Have you looked at UserAgent strings recently?

There was some “cache poisoning” going on where UserAgent string similar (but not equal) to standard Safari browsers could not be recognized properly and was identified as Mozilla 0.0, then it was cached with the first 64 characters of the UserAgent string as key which just happened to be exactly equal to that of oh so many normal Safaris…

Setting the userAgentCacheKeyLength to 256 solved the problem, even though there are still UserAgent strings out there that are identified as Mozilla 0.0. At least now it’s consistent.

Ad
Categories: Uncategorized Tags:
  1. July 2nd, 2012 at 15:52 | #1

    I have been chasing this bug for months. You are sooooooo awesome to have posted this info. You deserve the “amazing developer” award! I can’t wait to try this solution an see if it helps my issue. I can confirm though that what I’m seeing _exactly_ matches what you were seeing. Thanks a ton!

    -Ron

  2. ASP.NET
    August 2nd, 2012 at 20:35 | #2

    Additional observation: A user agent with an AppleWebkit and/or Safari version like 533.3 causes degraded functionality, whereas 533.3.0 works. It looks as though APS.NET 4 is not recognizing versions with only 2 dot-separated numbers even though it’s perfectly valid and there are versions of safari like that.

  1. No trackbacks yet.
*