我有一个相当详细的问题，我希望有人可以提供帮助。基本上，我有一个在IIS7上托管的.NET 4.0网站，它有一些页面需要重写URL。为了实现这些功能，我在global.asax中添加了一个方法，将无扩展的URL映射到正确的ASPX页面，然后执行context.RewritePath以显示正确的页面。
最初，我从application_BeginRequest调用了这个方法。但是，我们在调用Session_Start时会发生一些业务必需的日志记录，并且看起来这种日志记录并不总是发生，因为在application_BeginRequest中实现URL重写 - 基本上，每个会话都记录在数据库中，并且在初始部署之后URL重写，我们的会话日志下降了大约20％，应用程序日志中没有相应的错误。与此同时，我们的IIS日志似乎显示出相对不变的流量，所以在我看来，会话似乎没有正确实例化。
作为此问题的解决方法，我将URL重写从application_BeginRequest移至application_AcquireRequestState，因此在我（大部分）确定会话已启动之后，此代码才会触发。这适用于我的本地开发环境和登台服务器（Windows Server 2008 - 安装了IIS 7 - .NET 4.5 Framework）。在生产环境（Windows Server 2008 - IIS 7 - .NET 4.5 Framework）中，尝试浏览要重写的无扩展URL时出现404错误。
我完全难过 - 我已经验证我正在使用集成应用程序池，我的web.config具有“runAllManagedModulesForAllRequests = true”属性，我的IIS功能包括HTTP重定向和静态文件压缩，但没有出现任何内容工作。我发现使用Classic应用程序池，并创建额外的脚本地图处理程序以处理没有扩展名的通配符URL，但是我对在生产中将其放置到位时犹豫不决。
非常感谢您提供的任何帮助。谢谢！
答案 0 :(得分：0)
我会集中讨论会话日志下降20％的原因。你确定没有流量下降吗？您是否使用旧的.aspx网址为访问您网站的用户重定向？也许您收到了更多不会触发Session_Start的404流量？在UrlRewite推出后，Google Analytics是否确认流量维持在正常水平？您还可以使用IIS Log Parser过滤掉静态文件，并从日志文件中查询200与404，以更好地了解实际流量。