我有一个应用程序正在IIS 6.0上使用已经运行多年的ASP.NET 4.0 Webforms。 最近部署到应用程序导致了一些非常随机的（对我们来说）Safari浏览器（不是任何其他浏览器）的间歇性问题。
服务器重新启动后，应用程序似乎在一段时间内工作正常，但随后会“断开”。
它是100％的服务器级别，因为它在所有计算机上都能find，直到它“中断”。 一旦被破坏，就会在运行该版本的Safari的每台计算机上发生故障。 它改变了Safari版本，或者在http和https之间切换，它将再次工作，直到该版本“中断”
看起来中断是与发送给服务器的头文件相关联的。
一旦“中断”它有问题与CSS应用于ASP.NET控件，addhistory方法抛出javascript错误，因为它找不到__dopostback函数。
答案发现在： https : //stackoverflow.com/questions/5478181/net-4-0-website-cannot-identify-some-applewebkit-based-browsers
UserAgent – > BrowserCapsparsing机制使用caching来临时存储映射，不幸的是，它使用（默认情况下）UserAgentstring的前64个字符作为caching键，THAT是只是BS …偶尔会出现一个用户代理，看起来像一个Safari，但实际上并不是这样，一个没有正确解决（Mozilla 0.0），但映射仍然存储在caching中，这意味着所有UserAgentstring同样的64个字符前缀现在也被错误地映射，直到该caching项目过期（滑动窗口1分钟），用于caching的密钥长度可以幸运地用
<browserCaps userAgentCacheKeyLength="..." />在configuration部分。
我已经把关键长度提高到了256，因为这个问题已经消失了。 现在我将尝试找出哪个UserAgentstring在第一个位置对caching中毒负责 – 如果发现任何问题，我会更新这个post。“