IIS7, RewritePath and IIS log files

Question

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

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

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

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

This kind of code worked perfectly under IIS6.

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

Thanks.

EDIT:

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?

EDIT:

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

"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.

Answer 1

I've had exactly the same problem. One way around this is to use Server.Transfer instead of Context.RewritePath. Server.Transfer doesn't restart the entire page lifecycle so the original URL will still be logged. Be sure to pass "true" for the "preserveForm" parameter so that the QueryString and Form collections are available to the 2nd page.

Answer 2

Old question, but I found I did not encounter your problem when I did the following:

a) A rewrite rule in web.config to direct all requests to /default.aspx, eg:

    <rule name="all" patternSyntax="Wildcard" stopProcessing="true">
      <match url="*"/>
      <action type="Rewrite" url="/default.aspx"/>
    </rule>

b) Called RewritePath in the Page_PreInit event of default.aspx, to rewrite the URL and querystring as what was passed in the request (ie. the location that doesn't exist).

For example, I request "/somepage/?x=y" (which doesn't exist).

a) Web.config rule maps it to /default.aspx

b) Page_PreInit rewrites it back to "/somepage/?x=y".

The result of this, in IIS 7 (Express and production) is that the server log reflects "/somepage" for stub and "x=y" for query, and all the Request object properties reflect the requested (non-existent) URL (which is what I wanted).

The only weird effect is, in IIS Express, the log item is written twice. However this doesn't happen in production (Windows Server 2008 R2).

Answer 3

You could set the path back to the original value after the request has been processed but before the IIS logging module writes the log entry.

For example, this module rewrites the path on BeginRequest and then sets it back to the original value on EndRequest. When this module is used the original path appears in the IIS log file:

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()
    {

    }
}

Answer 4

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

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

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.

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

I'll be back with the update.

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.