Glengamoi (Forum) · AspHeute · .NET Heute (RSS-Suche) · AspxFiles (Wiki) · .NET Blogs

Serverseitige Redirects mit IIS5

Geschrieben von: Christoph Wille
Kategorie: ASP Tricks

This printed page brought to you by AlphaSierraPapa

Eine Methode des Response Objekts von IIS4 dürfte vielen Programmierern Header-Schmerzen verschafft haben: Response.Redirect. Mit dieser Methode kann man einen Benutzer von Seite A nach Seite B umleiten, und zwar mit Hilfe des HTTP Status Codes 302, Object Moved. Hier als Beispiel die Hauptseite von www.aspgerman.com: 

HTTP/1.1 302 Object moved
Location: /aspgerman/
Diese HTTP Header werden an den Browser geschickt, der dann die neue Seite aufruft. Im Fließbild sieht das dann wie folgt aus:

In Schritt 1 wird die Seite aufgerufen, die mitteilt, daß eine andere Seite angesprungen werden soll. Dies führt der Browser automatisch in Schritt 3 durch. Das hat natürlich den Nachteil, daß der Benutzer eine weitere Anfrage an den Web Server abwarten muß.

Mit IIS 5 unter Windows 2000 sind 2 neue Methoden für serverseitige Redirects eingebaut worden:

Server.Transfer - die GoTo Variante

Die erste Spielart der neuen Server-Redirects ist Server.Transfer. Bei dieser Technik bricht das aktuell ausgeführte ASP Skript in der Zeile ab, in der Server.Transfer steht. Von da an übernimmt das aufgerufene Skript. Wichtig ist, daß der Client am Ende der Ausführung nach wie vor die URL von der anfänglich aufgerufenen Seite sieht.

Dieses Konzept verdeutlicht das folgende Fließbild:

Um es auch "angreifbar" zu machen, habe ich hier beispielhaft SeiteA.asp und SeiteB.asp programmiert, hier der Code für SeiteA.asp: 

<html>
<head><title>Seite A</title></head>
<body>

Das ist Seite A, erster Output<br>

<% Server.Transfer "SeiteB.asp" %>

Das sieht niemand jemals wieder!<br>

</body>
</html>
Und dies ist der Code in SeiteB.asp: 
Und jetzt bin ich auf Seite B!


</body>
</html>
Der Output ist erwartungsgemäß 
Das ist Seite A, erster Output
Und jetzt bin ich auf Seite B!

Wie gesagt, Seite A bricht mit der Abarbeitung zu dem Zeitpunkt ab, wo Server.Transfer ausgeführt wird. Deswegen habe ich in SeiteB.asp auch die HTML Endecodes eingebaut - weil die entsprechenden von SeiteA.asp ja nicht mehr aufgerufen würden.

Ein Vorteil von Server.Transfer ist der, daß die gesamten ASP Objekte wie Request, Response, Session oder Application ihre Werte behalten, was auch bedeutet, daß ich auf Seite B auf den QueryString von Seite A zugreifen kann. Und natürlich habe ich Zugriff auf alle Session und Application Variablen. Genauso selbstverständlich allerdings kann man auf in Seite A deklarierte normale Variablen (VBScript) nicht mehr zugreifen.

Server.Execute - die prozedurale Variante

Obwohl Server.Execute am ehesten mit einem Prozeduraufruf verglichen werden kann, teilt .Execute ansonsten die Funktionalität von .Transfer: alle ASP Objekte sind unmodifiziert verfügbar. Allerdings fährt die Ausführung der aufrufenden Seite nach .Execute weiter:

Um das Konzept zu verdeutlichen, habe ich wieder beispielhaft SeiteA.asp und SeiteB.asp programmiert; zuerst nun der Code für SeiteA.asp: 

<html>
<head><title>Seite A</title></head>
<body>

Das ist Seite A, erster Output<br>

<% 
Server.Execute("SeiteB.asp")
%>

Das ist Seite A, zweiter Output<br>

</body>
</html>
Und dies ist der Code in SeiteB.asp, der in Seite A nach der Ausführung eingebunden wird: 
Seite B wird ausgeführt!<br>
Der Output ist, wie erwartet 
Das ist Seite A, erster Output
Seite B wird ausgeführt!
Das ist Seite A, zweiter Output

Als typischter Anwendungsfall für Server.Execute dürften sich wahrscheinlich dynamische Includes herauskristallisieren. Man kann sowohl relative Pfade, als auch Absolutpfade für den Aufruf verwenden (gilt auch für .Transfer). Für die Absolutpfadvariante gilt allerdings eine Einschränkung: das aufgerufene ASP Skript muß Teil der Web Applikation sein, der auch die aufrufende Seite angehört.

Schlußbemerkung

Für das serverseitige Programmieren sind die beiden neuen Funktionen Server.Execute und Server.Transfer sicherlich ein Gewinn. Allerdings wird ein gewisses Anwendungsgebiet für Response.Redirect niemals verschwinden - den Benutzer zu einer URL auf einem anderen Server zu schicken. Beide Server Methoden funktionieren nämlich nur für Skripts am lokalen Server.

This printed page brought to you by AlphaSierraPapa

Verwandte Artikel

ASP-Fehlerbehandlung unter IIS5
http:/www.aspheute.com/artikel/20000512.htm

Links zu anderen Sites

Using a Query String in the IIS Server.Execute Parameter Produces an Error
http://support.microsoft.com/support/kb/articles/Q247/4/20.ASP

 

©2000-2006 AspHeute.com
Alle Rechte vorbehalten. Der Inhalt dieser Seiten ist urheberrechtlich geschützt.
Eine Übernahme von Texten (auch nur auszugsweise) oder Graphiken bedarf unserer schriftlichen Zustimmung.