Ich verstehe, dass beide die URL, die der Client sieht, nicht ändern. Gibt es irgendetwas in ihnen, das einen von ihnen gegenüber dem anderen bevorzugt?
Ich plane, es in der Application_BeginRequest in Global.asax, sondern auch in regulären Aspx-Seite zu verwenden.Server.Transfer vs. Context.RewritePath
Ich denke, Context.RewritePath() ist die bessere Option. Grund:
Server.Transfer() wirft ein ThreadAbortException jedes Mal. Das Ergebnis des Aufrufs Response.End().
Für weitere Informationen lesen Sie die folgenden MS Artikel:
Weitere Informationen:
Server.Transfer() keine HTTP 302-Umleitung Befehl sendet als Response.Redirect() tun würde, .
Gemäß HttpContext.RewritePath on MSDN wird RewritePath() im Sitzungszustand ohne Cookies verwendet.
Auch zu einem anderen Thema, Server.Transfer() und Server.Execute() sind sehr unterschiedlich:
Server.Execute() gibt die Steuerung an der ersten Seite unmittelbar nach dem es hieß.
Beispiel:
<div>
test 1 <br/>
<% Server.Execute("include.aspx?hello=ok"); %>
test 2 <br/>
</div>
ausgeben würde:
Test 1
Inhalt include.aspx hallo = ok
Test 2
Kontext. RewritePath Weist einen internen Umschreibepfad zu und ermöglicht, dass die angeforderte URL vom internen Pfad zur Ressource abweicht. RewritePath wird im Sitzungszustand ohne Cookies verwendet.
Während Server.transfer überträgt den Inhalt für die Verarbeitung einer Seite zusammengestellt auf eine andere Seite.
Um die von Server.Transfer ausgelöste Ausnahme zu vermeiden, können Sie Server.Execute verwenden. Sowohl Server.Transfer als auch Server.Execute geben KEINE 302 HTTP-Nachricht aus. Nur Response.Redirect gibt diese Kopfzeile aus und fordert den Browser auf, zu dem neuen Ziel zu gehen, mit der Begründung, dass es vorübergehend verschoben wurde. Mit Server.Transfer und Server.Execute können Sie eine andere Seite ausführen, um die aktuelle Anforderung zu bedienen.