IIS7, RewritePath und IIS-Protokolldateien

stimmen
10

Ich verwende Context.RewritePath () in ASP.NET 3.5-Anwendung auf IIS7 ausgeführt wird.

Ich tue es in Anwendung Beginrequest Ereignis und alles funktioniert Datei.

Anträge auf / Sport neu geschrieben werden, um richtig default.aspx? Id = 1, und so weiter.

Das Problem ist, dass in meinem IIS-Protokoll sehe ich GET-Anfragen für /Default.aspx?id=1 und nicht für / Sport.

Diese Art von Code funktionierte perfekt unter IIS6.

Microsoft Rewrite-Modul ist keine Option, aufgrund einiger Business-Logik, die umgesetzt werden muss.

Vielen Dank.

BEARBEITEN:

Es scheint, mein Handler in der Pipeline zu früh ist, aber wenn ich die Logik zu einem späteren Ereignisse bewegen, als die ganze Sache Rewrite funktioniert nicht (es ist zu spät, nimmt StaticFileHandler meine Anfrage nach oben).

Ich googeln und gegoogelt, fragte herum, kann nicht glauben, dass niemand dieses Problem hat?

BEARBEITEN:

Huch! Hier ist, was ich auf dem IIS-Forum gefunden:

„Das liegt daran, dass im integrierten Modus, IIS und asp.net eine gemeinsame Pipeline und die RewritePath jetzt von IIS, während in IIS6 zu sehen sind, ist es nicht einmal von IIS gesehen wurde - Sie dies durch die Verwendung klassischen Modus umgehen können, die wie verhalten IIS6.“

Schluss Update : Bitte werfen Sie einen Blick auf meine Antwort unten , ich habe es mit den Ergebnissen aktualisiert , nachdem mehr als ein Jahr in der Produktionsumgebung.

Veröffentlicht am 09/12/2008 um 18:15
quelle vom benutzer
In anderen Sprachen...                            


4 antworten

stimmen
6

Nach einigen Recherchen habe ich fand schließlich eine Lösung für das Problem.

Ich habe die Anrufe an Context.RewritePath () -Methode mit der neuen (eingeführt in ASP.NET 3.5) ersetzt Context.Server.TransferRequest () Methode.

Es scheint jetzt offensichtlich, aber nicht Ereignis Profi Dev Engineer IIS Kernteam Gedanken daran.

Ich habe es für die Sitzungs getestet, Authentifizierung, Postbacks, Abfragezeichenfolgeflag, ... Fragen und fand keine.

Tommorow Ich werde die Änderung zu einem sehr Höhe Verkehr Standort bereitstellen, und wir werden bald wissen, wie es tatsächlich funktioniert. :)

Ich werde mit dem Update wieder.

Das Update: die Lösung ist noch nicht ganz auf meinen Produktionsserver aber es getestet und es funktioniert und soweit ich bisher sagen kann, ist es eine Lösung für mein Problem. Wenn ich irgendetwas anderes in der Produktion zu entdecken, werde ich ein Update veröffentlichen.

Die letzte Update: Ich habe diese Lösung in der Produktion seit über ein Jahr und es hat eine gute und stabile Lösung ohne Probleme erwiesen.

Beantwortet am 23/02/2009 um 21:15
quelle vom benutzer

stimmen
4

Sie könnten den Weg zurück auf den ursprünglichen Wert eingestellt, nachdem die Anforderung verarbeitet wurde, aber vor dem IIS Logging-Modul schreibt den Protokolleintrag.

Zum Beispiel umschreibt dieses Modul den Weg auf BeginRequestund dann setzt es auf den ursprünglichen Wert zurück EndRequest. Wenn dieses Modul verwendet wird , erscheint der ursprüngliche Pfad in der IIS - Protokolldatei:

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

    }
}
Beantwortet am 17/02/2009 um 19:14
quelle vom benutzer

stimmen
2

Ich habe genau das gleiche Problem hat. Ein Weg, um dies ist Server.Transfer statt Context.RewritePath zu verwenden. Server.Transfer nicht neu gestartet wird, die gesamte Seite Lebenszyklus, so dass die ursprüngliche URL noch protokolliert. Achten Sie darauf, „true“ für die „PreserveForm“ Parameter zu übergeben, so dass die Abfrage-Zeichenfolge und Formularsammlungen zur 2. Seite zur Verfügung stehen.

Beantwortet am 17/02/2009 um 19:34
quelle vom benutzer

stimmen
0

Alte Frage, aber ich fand ich habe Ihr Problem nicht auf, wenn ich das folgende tat:

a) Eine Rewrite-Regel in web.config alle Anfragen direkt an /Default.aspx, zB:

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

b) Wird aufgerufen , RewritePath im Page_PreInitFalle default.aspx, die URL und Abfragezeichenfolgeflag als neu zu schreiben , was in der Anfrage übergeben wurde (dh. die Position, die nicht existiert).

Zum Beispiel habe ich bitten „/ somepage /? X = y“ (die es nicht gibt).

a) Web.config Regel ordnet sie /Default.aspx

b) Page_PreInit es wieder neu schreibt auf "/ somepage /? x = y".

Dies hat zur Folge, in IIS 7 (Express und Produktion) ist, dass der Server-Log „/ somepage“ für Stub und „x = y“ für Abfrage reflektiert und alle Request-Objekt-Eigenschaften spiegeln die angeforderte (nicht vorhanden) URL ( das ist, was ich wollte).

Der einzige seltsame Effekt wird, in IIS Express, wird das Protokoll Element zweimal geschrieben. Doch dies geschieht nicht in der Produktion (Windows Server 2008 R2).

Beantwortet am 06/01/2013 um 10:54
quelle vom benutzer

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more