IIS7，RewritePath和IIS日志文件 [英] IIS7, RewritePath and IIS log files

问题描述

我在ASP.NET 3.5应用程序中使用Context.RewritePath（）上运行的IIS7

I am using Context.RewritePath() in ASP.NET 3.5 application running on IIS7.

我做它的应用BeginRequest事件和一切工作的文件。

I am doing it in application BeginRequest event and everything works file.

有关/运动请求被正确重写的Default.aspx？ID = 1，依此类推。

Requests for /sports are correctly rewritten to default.aspx?id=1, and so on.

问题是，在我的IIS日志我请参阅获取/Default.aspx?id=1而不是/运动请求。

The problem is that in my IIS log I see GET requests for /Default.aspx?id=1 and not for /sports.

这种code的IIS6下完美。

This kind of code worked perfectly under IIS6.

使用Microsoft重写模块是不是一种选择，因为它必须要实现一些业务逻辑。

Using Microsoft Rewrite module is not an option, due to some business logic which has to be implemented.

感谢。

编辑：

看来我的处理程序是在管线为时尚早，但如果我将逻辑到以后的事件，比整个重写的东西不能正常工作（这是为时已晚，StaticFileHandler拿起我的要求）。

It seems my handler is too early in the pipeline, but if I move the logic to a later event, than the whole rewrite thing doesn't work (it's too late, StaticFileHandler picks up my request).

我一派和一派，四处打听，也不能相信没有人有这个问题？

I googled and googled, asked around, can't believe that nobody has this problem?

编辑：

哎呀！下面是我在IIS论坛找到：

Yikes! Here's what I found on the IIS forum:

这是因为在集成模式下，IIS和asp.net共用一个管道与RewritePath由IIS现在看到的，而在IIS6，它甚至不是由IIS看到 - 你可以通过使用经典模式解决此哪些会表现得像IIS6。

"This is because in integrated mode, IIS and asp.net share a common pipeline and the RewritePath is now seen by IIS, while in IIS6, it was not even seen by IIS - you can workaround this by using classic mode which would behave like IIS6."

最后一次更新：请看一看的下面我的回答，我已经后的结果更新它比在生产环境中的一年。

Final update: Please take a look at my answer below, I've updated it with results after more than a year in production environment.

推荐答案

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

After some research, I've finally found a solution to the problem.

我已经更换到Context.RewritePath（）方法，用新的（在ASP.NET 3.5中引入） Context.Server.TransferRequest（）方法的调用。

I have replaced the calls to Context.RewritePath() method with the new (introduced in ASP.NET 3.5) Context.Server.TransferRequest() method.

现在似乎是显而易见的，但重要的是IIS核心团队的思想不是事件的高级开发工程师。

It seems obvious now, but not event Senior Dev Engineer on IIS Core team thought of that.

我测试过它的会话，认证，回传，查询字符串，...问题找不着。

I've tested it for session, authentication, postback, querystring, ... issues and found none.

的明天，我会部署变化很HIGHT流量的网站，并且我们很快就会知道它是如何实际工作。 :)

Tommorow I'll deploy the change to a very hight traffic site, and we'll soon know how it actually works. :)

我会回来的更新。

更新：解决方案仍然是不完全在我的生产服务器，但它的测试，它的工作，并就我目前可以告诉，这是我的问题的解决方案。如果我发现别的生产，我会发布更新。

The update: the solution is still not entirely on my production servers but it's tested and it does work and as far as I can tell so far, it's a solution to my problem. If I discover anything else in production, I will post an update.

最后更新：我有一年多生产这种解决方案，它已被证明是没有任何问题了良好，稳定的解决方案

The final update: I have this solution in production for over a year and it has proven to be a good and stable solution without any problems.

这篇关于IIS7，RewritePath和IIS日志文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！