IIS7、RewritePath和IIS日志文件
我在运行在Context.RewritePath上的ASP.NET 3.5应用程序中使用了IIS7 ()。
我是在应用程序BeginRequest事件中这样做的，所有的事情都在文件中工作。
对/sports的请求被正确地重写为default.aspx?id=1，依此类推。
问题是，在我的IIS中，我看到了GET请求/Default.aspx?id=1，而不是/sports。
这类代码在IIS6下工作得很好。
使用Microsoft重写模块并不是一种选择，因为某些业务逻辑必须实现。
谢谢。
编辑：
看来我的处理程序还太早，但是如果我将逻辑转移到稍后的事件，那么整个重写就不能工作了(为时已晚，StaticFileHandler接收到了我的请求)。
我谷歌了一下，问了一遍，不敢相信没有人有这个问题？
编辑：
呀！下面是我在IIS论坛上发现的内容：
“这是因为在集成模式下，IIS和asp.net共享一个公共管道，RewritePath现在被IIS看到，而在IIS6中，IIS甚至看不到它--您可以通过使用行为类似于IIS6的经典模式来解决这个问题。”
最终更新：请看一下my answer below，我已经在生产环境中使用了一年多的结果更新了它。
回答 4
Stack Overflow用户
发布于 2009-02-23 20:15:10
经过一番研究，我终于找到了解决这个问题的办法。
我已经将对Context.RewritePath()方法的调用替换为新的(在ASP.NET 3.5中引入的)ASP.NET方法。
现在看来很明显，但IIS核心团队中的高级开发工程师并没有想到这一点。
我已经测试过它的会话，认证，回发，查询字符串，.没有发现任何问题。
明天，我将把更改部署到一个非常高的流量站点，我们很快就会知道它是如何工作的。:)
我会带着更新回来的。
更新：解决方案仍然不是完全在我的生产服务器上，但它已经过测试，而且确实有效，据我所知，它是解决我的问题的一个解决方案。如果我在生产中发现了其他的东西，我会发布一个更新。
，最后一次更新：--我已经在生产中使用了这个解决方案超过一年，并且已经证明是一个很好的、稳定的解决方案，没有任何问题。
Stack Overflow用户
发布于 2009-02-17 18:14:37
您可以在处理请求之后，但在IIS日志记录模块写入日志条目之前，将路径设置为原始值。
例如，该模块在BeginRequest上重写路径，然后将其设置为EndRequest上的原始值。当使用此模块时，原始路径出现在IIS日志文件中：
public class RewriteModule : IHttpModule
{
public void Init(HttpApplication context)
{
context.BeginRequest += OnBeginRequest;
context.EndRequest += OnEndRequest;
}
static void OnBeginRequest(object sender, EventArgs e)
{
var app = (HttpApplication)sender;
app.Context.Items["OriginalPath"] = app.Context.Request.Path;
app.Context.RewritePath("Default.aspx?id=1");
}
static void OnEndRequest(object sender, EventArgs e)
{
var app = (HttpApplication)sender;
var originalPath = app.Context.Items["OriginalPath"] as string;
if (originalPath != null)
{
app.Context.RewritePath(originalPath);
}
}
public void Dispose()
{
}
}Stack Overflow用户
发布于 2009-02-17 18:34:12
我也遇到过同样的问题。解决这个问题的一种方法是使用Server.Transfer而不是Context.RewritePath。Server.Transfer不会重新启动整个页面生命周期，所以原始的URL仍然会被记录下来。确保为"preserveForm“参数传递"true”，以便QueryString和Form集合可用于第2页。
https://stackoverflow.com/questions/353541
复制相似问题
腾讯云开发者
