IIS7 RewritePath-und IIS-log-Dateien

Bin ich mit dem Kontext.RewritePath() in ASP.NET 3.5 Anwendung auf IIS7.

Tue ich es in der Anwendung BeginRequest-Ereignis und alles funktioniert Datei.

Anforderungen für /Sport-korrekt umgeschrieben Standard.aspx?id=1, und so weiter.

Das problem ist, dass in meinem IIS log sehe ich Anfragen BEKOMMEN für /Default.aspx?id=1 und nicht für /Sport.

Diese Art von code funktionierte perfekt unter IIS6.

Mithilfe von Microsoft Rewrite-Modul ist keine option, aufgrund von einigen business-Logik umgesetzt werden.

Dank.

EDIT:

Es scheint, mein handler ist zu früh in der pipeline, aber wenn ich mich bewege die Logik zu einem späteren Zeitpunkt, als das ganze umschreiben, was nicht funktioniert (es ist zu spät, StaticFileHandler nimmt meine Anfrage).

Habe ich gegoogelt und gegoogelt, fragte herum, kann nicht glauben, dass niemand dieses problem hat?

EDIT:

Huch! Hier ist was ich gefunden habe auf dem IIS-forum:

"Das ist, weil die im integrierten Modus von IIS und asp.net eine gemeinsame pipeline und die RewritePath jetzt gesehen, IIS, während in IIS6, es war noch gar nicht gesehen, die von IIS - Sie können dies umgehen, indem mit dem classic-Modus Verhalten würde wie IIS6."

Letzten update: Bitte werfen Sie einen Blick auf unten meine Antwort, ich habe aktualisiert es mit den Ergebnissen nach mehr als einem Jahr in der Produktionsumgebung.

  • Ich würde (und habe) nur auf das System blicken.Web.Routing-assembly via Reflektor. Um zu sehen, wo es Haken bis. IIRC, die Sie brauchen, um es in PostMapRequestHandler und PostAcquireRequestState.
  • Ich habe versucht, das, wie ich schrieb in meinem EDIT, aber das Ereignis ist zu spät in der pipeline...
  • Ich Las Ihre updates. Gibt es keine Möglichkeit, können Sie fügen Sie einen Ereignis-handler, der irgendwo in der Anwendung? Ich meine, der Antrag muss irgendwo enden. Meine Experimente mit custom umschreiben erwies sich auch als schwierig.
  • Ich habe versucht, fast alle Veranstaltungen. Entweder ich lose Protokollierung, entweder die Umschreibung ist zu spät, oder ich lockere session-Zustand... 🙁 ich kann nicht glauben, dass NIEMAND diese Probleme hatte?
  • Muerte, der richtige Weg, dies zu tun wäre, um Ihre eigene Frage zu beantworten. Sie erklärte, dass dieses Problem können Sie beheben indem Sie IIS 7 in classic-Modus, der die gleiche Weise wie IIS 6. Solange Sie erkennen, dass Sie nicht profitieren von den Sicherheits-oder performance-upgrades in die neue IIS 7 indem du dies tust, dann scheint es wie eine vernünftige Antwort.
  • Ich verstehe, dass ich Antwort auf meine eigene Frage, aber ich denke nicht, dass dies als Antwort an alle und ich bin immer noch der Verfolgung der Suche. 🙂 Ich bin versucht, einige Dinge, und ich werde auf jeden Fall mein Ergebnis, entweder als Antwort oder als ein letzter edit zu meiner Frage.

InformationsquelleAutor markom | 2008-12-09
  1. 6

    Nach einigen Forschung, habe ich endlich eine Lösung gefunden für das problem.

    Habe ich ersetzt die Aufrufe zum Kontext.RewritePath () - Methode mit der neuen (eingeführt in ASP.NET 3.5) Kontext.Server.TransferRequest() Methode.

    Es scheint nun offensichtlich, aber nicht Ereignis Senior Dev-Ingenieur am IIS-Core-team gedacht.

    Getestet hab ich es für session-Authentifizierung, Postbacks, querystring, ... Fragen und keine gefunden.

    Morgen werde ich bereitstellen, die änderung eine sehr hohe Verkehrs Website, und wir werden bald wissen, wie es tatsächlich funktioniert. 🙂

    Werde ich wieder mit dem update.

    Update: die Lösung ist noch nicht ganz auf meinem prod-Server, aber es ist getestet und es funktioniert und soweit ich das bisher beurteilen kann, ist es eine Lösung zu meinem problem. Wenn ich irgendetwas anderes in der Produktion, ich poste ein update.

    Dem letzten update: ich habe diese Lösung in der Produktion für über ein Jahr und es hat sich bewährt, um eine gute und stabile Lösung ohne Probleme.

    • Warum scheint es so offensichtlich ist?
    InformationsquelleAutor markom
  2. 4

    Konnten Sie den Weg zurück auf den ursprünglichen Wert, nachdem die Anfrage bearbeitet wurde, aber bevor die IIS-Protokollierung-Modul schreibt den log-Eintrag.

    Beispielsweise dieses Modul schreibt den Pfad auf BeginRequest und dann setzt es zurück auf den ursprünglichen Wert auf EndRequest. Wenn dieses Modul verwendet die original-Pfad wird 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()
    {

    }
}
    • Ja ich habe es getestet auf Vista mit IIS 7 und geprüft, dass die web-Seite sah der umgeschriebenen Pfad aber, dass der ursprüngliche Weg wurde geschrieben, um die IIS-log-Datei. Aber ich bin noch nicht zum ausführlichen testen welche Nebenwirkungen dies zu tun haben könnte.
    InformationsquelleAutor Daniel Richardson
  3. 2

    Ich habe genau das gleiche problem hatte. Ein Weg, um dieses ist die Verwendung von Server.Transfer statt Kontext.RewritePath. Server.Transfer nicht neu starten, die gesamte Seite-Lebenszyklus, so dass die ursprüngliche URL weiterhin protokolliert. Werden Sie sicher, dass pass "true" für die "preserveForm" - parameter, so dass der QueryString und Form Sammlungen sind verfügbar auf der 2. Seite.

    InformationsquelleAutor David
  4. 0

    Alte Frage, aber ich fand ich nicht begegnen Ihr problem, wenn ich Folgendes gemacht:

    a) Eine rewrite-Regel im web.config richten Sie alle Anfragen an /default.aspx, zB:

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

    b) Genannt RewritePath in der Page_PreInit Verzug.aspx, zum umschreiben der URL und querystring als das, was war in der Anfrage übergeben (dh. der Ort, der nicht existiert).

    Ich zum Beispiel-Anfrage "/somepage/?x=y" (die nicht existiert).

    a) Web.config-Regel ordnet Sie /default.aspx

    b) Page_PreInit schreibt wieder in "/somepage/?x=y".

    Das Ergebnis dieser, im IIS 7 (Express und Produktion) ist, dass die server-log-reflektiert "/somepage" für die stub-und "x=y" für die Abfrage, und alle Request-Objekt Eigenschaften spiegeln, die angefordert (nicht existierende) URL (das ist das, was ich wollte).

    Nur die komische Wirkung, in IIS Express, das Protokoll-Element ist zweimal geschrieben. Geschieht dies jedoch nicht in der Produktion (Windows Server 2008 R2).

    InformationsquelleAutor ingredient_15939
Schreibe einen Kommentar