IIS7、RewritePath 和 IIS 日志文件

我在 IIS7 上运行的 ASP.NET 3.5 应用程序中使用 Context.RewritePath() 。

我正在应用程序 BeginRequest 事件中执行此操作，并且一切正常文件。

/sports 的请求被正确重写为default.aspx?id=1，依此类推。

问题是，在我的 IIS 日志中，我看到 /Default.aspx?id=1 的 GET 请求，而不是 /sports 的请求。

这种代码在IIS6下完美运行。

由于必须实现一些业务逻辑，因此不能选择使用 Microsoft Rewrite 模块。

Thanks.

EDIT:

看来我的处理程序在管道中太早了，但是如果我将逻辑移至稍后的事件，则整个重写操作将不起作用（为时已晚，StaticFileHandler 接受了我的请求）。

我用谷歌搜索了又搜索，四处询问，不敢相信没有人遇到这个问题？

EDIT:

哎呀！以下是我在 IIS 论坛上找到的内容：

“这是因为在集成模式下，IIS 和 asp.net 共享一个公共管道，并且 IIS 现在可以看到 RewritePath，而在 IIS6 中，IIS 甚至看不到它 - 您可以通过使用经典模式来解决此问题，其行为如下IIS6。”

最终更新: 请看一下我的回答如下 https://stackoverflow.com/questions/353541/iis7-rewritepath-and-iis-log-files/579141#579141，我已经在生产环境中使用了一年多的结果更新了它。

经过一番研究，我终于找到了解决问题的方法。

我已将对 Context.RewritePath() 方法的调用替换为新方法（在 ASP.NET 3.5 中引入）Context.Server.TransferRequest() method.

现在看来这是显而易见的，但 IIS Core 团队的高级开发工程师并没有想到这一点。

我已经测试了它的会话、身份验证、回发、查询字符串等问题，但没有发现任何问题。

明天我会将更改部署到一个流量非常高的站点，我们很快就会知道它的实际工作原理。 :)

我会带着更新回来的。

更新：该解决方案仍然不完全在我的生产服务器上，但它已经过测试并且确实有效，据我所知，到目前为止，它是我的问题的解决方案。如果我在生产中发现任何其他内容，我将发布更新。

最终更新：我已经在生产中使用这个解决方案一年多了，事实证明它是一个良好且稳定的解决方案，没有任何问题。