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

Serverseitige Redirects mit IIS5

Geschrieben von: Christoph Wille
Kategorie: ASP Tricks

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 übergibt die Kontrolle von Seite A an Seite B. Funktioniert im Prinzip wie das altbekannte GoTo Statement.
Server.Execute führt Seite B von Seite A aus aus, und Seite A beendet den Response. Vergleichbar mit dem Aufruf einer Prozedur in Visual Basic.

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.

Links zu anderen Sites

Using a Query String in the IIS Server.Execute Parameter Produces an Error

Wenn Sie jetzt Fragen haben...

Wenn Sie Fragen rund um die in diesem Artikel vorgestellte Technologie haben, dann schauen Sie einfach bei uns in den Community Foren der deutschen .NET Community vorbei. Die Teilnehmer helfen Ihnen gerne, wenn Sie sich zur im Artikel vorgestellten Technologie weiterbilden möchten.

Haben Sie Fragen die sich direkt auf den Inhalt des Artikels beziehen, dann schreiben Sie dem Autor! Unsere Autoren freuen sich über Feedback zu ihren Artikeln. Ein einfacher Klick auf die Autor kontaktieren Schaltfläche (weiter unten) und schon haben Sie ein für diesen Artikel personalisiertes Anfrageformular.

Und zu guter Letzt möchten wir Sie bitten, den Artikel zu bewerten. Damit helfen Sie uns, die Qualität der Artikel zu verbessern - und anderen Lesern bei der Auswahl der Artikel, die sie lesen sollten.