URL-Umschreiben für ASP.NET Web Forms

von Ruslan Yakushev

Wenn Sie das IIS-URL-Rewrite-Modul mit ASP.NET-Anwendungen verwenden, ist es wichtig, das richtige Verhalten Ihrer Webanwendung mit umgeschriebenen URLs sicherzustellen. In diesem Artikel werden Szenarien erläutert, in denen sich die URL-Umschreibung auf ASP.NET-Webanwendungen auswirken kann, und Lösungen für potenzielle Probleme beschrieben.

Inhaltsverzeichnis

Festlegen der Postback-URL für das Form-Element

ASP.NET Web Forms verwendet sehr häufig Postbacks, die macht es schwierig machen können, URL-Umschreibungen für ASP.NET-Seiten durchzuführen. Wenn die Seite mindestens ein Webserversteuerelement enthält, legt ASP.NET beim Rendern der Seite das action-Attribute des HTML-Form-Elements so fest, dass es zurück auf die Seite verweist, auf der sich das Form-Element befindet, d. h., es verweist auf sich selbst. Wenn das URL-Umschreiben für diese Seite verwendet wird, verweist das action-Attribut auf die umgeschriebene URL, und nicht auf die URL, die vom Browser angefordert wurde. Dies führt dazu, dass der Browser bei einem Postback jedes Mal die umgeschriebene URL im Adressfeld anzeigt.

Um zu verhindern, dass das action-Attribut auf die falsche URL verweist, können Sie die Action-Eigenschaft der HtmlForm-Instanz auf der Seite auf die Postback-URL festlegen, die vom Browser angefordert wurde. Sie können diese URL mithilfe der HttpRequest.RawUrl-Eigenschaft abrufen. Das folgende Beispiel zeigt, wie Sie die ASP.NET-Seite ändern können, um die Aktions-URL festzulegen.

protected void Page_Load(object sender, EventArgs e) 
{ 
    form1.Action = Request.RawUrl; 
}

Hinweis

Die HtmlForm.Action-Eigenschaft ist ab .NET Framework Version 3.5 SP1 verfügbar.

Wenn Sie ASP.NET-Masterseiten verwenden, können Sie der Page_Load-Methode der Masterseite Code hinzufügen, um die Aktions-URL bei einem Postback für alle Seiten festzulegen, die diese Masterseite verwenden.

Umschreiben von URLs für das AJAX-UpdatePanel-Steuerelement

Wenn Sie das URL-Rewrite-Modul verwenden, um die URL für eine Seite umzuschreiben, die mindestens ein UpdatePanel-Steuerelement enthält, verwendet das Steuerelement die umgeschriebene URL für alle Aktionen, die von diesem UpdatePanel-Steuerelement ausgeführt werden. Dies kann dazu führen, dass die Steuerelemente im UpdatePanel-Steuerelement nicht ordnungsgemäß funktionieren, insbesondere in Fällen, in denen die URL-Umschreibung die Verzeichnishierarchie der angeforderten URL ändert. Wenn Sie z. B. das URL-Rewrite-Modul verwenden, um „/Products/Hardware in /Products.aspx“ umzuschreiben, verwendet das UpdatePanel-Steuerelement die URL „/Products/Hardware/Products.aspx“ für alle Aktionen innerhalb des UpdatePanel-Steuerelements. Dies führt zu einem Skriptfehler.

Um dies zu verhindern, legen Sie die Action-Eigenschaft der HtmlForm-Instanz der Seite wie unter Festlegen der Postback-URL für das Form-Element im vorherigen Abschnitt beschrieben fest.

Verwenden des ~-Operators in Webserversteuerelementen

Sie können den ~-Operator in ASP.NET-Webserversteuerelementen verwenden, um auf den Stamm des Anwendungsverzeichnisses zu verweisen, wenn Sie einen Pfad festlegen müssen. Wenn die URL-Umschreibung jedoch die Verzeichnishierarchie der angeforderten URL ändert, kann dies dazu führen, dass Verknüpfungen, die mit dem ~-Operator angegeben wurden, falsch aufgelöst werden. Gehen Sie beispielsweise davon aus, dass die Seite „Default.aspx“ im Stamm einer Webanwendung mit dem Namen „app1“ das folgende Bildsteuerelement enthält:

<asp:Image runat="server" ImageUrl="~/Images/MyImage.gif" />

Wenn die URL-Umschreibung die URL von http://localhost/app1/folder/file in http://localhost/app1/default.aspx ändert, werden die mit dem ~-Operator angegebenen Links relativ zum umgeschriebenen URL-Pfad aufgelöst – also relativ zum Ordner „/app1“. Das folgende Beispiel zeigt das resultierende HTML-Markup für das img-Element:

<img src="Images/MyImage.gif" ... >

Da der Browser http://localhost/app1/folder/file angefordert hat, versucht er, das Bild von http://localhost/app1/folder/Images/MyImage.gif abzurufen. Dies führt zum Fehler „404 (Datei nicht gefunden)“.

Das URL-Rewrite-Modul für IIS enthält ein Update für ASP.NET, das dieses Verhalten korrigiert. Das Update bewirkt, dass der ~-Operator in Webserversteuerelementen relativ zur ursprünglich angeforderten URL aufgelöst wird. Im vorherigen Beispiel enthält das HTML-Markup in der Antwort den richtigen URL-Pfad für das img-Element, wie im folgenden Markup gezeigt:

<img src="../Images/MyImage.gif" ... >

Das Update für ASP.NET gilt nur für .NET Framework 3.5 SP1 und höher. Um das Update zu erhalten, upgraden Sie .NET Framework auf Version 3.5 SP1, und führen Sie dann das Installationsprogramm für das IIS-URL-Rewrite-Modul aus, das auch das ASP.NET-Update installiert.

Umschreiben von URLs und Websitenavigationssteuerelementen

Mit einer ASP.NET-Sitemap kann die Struktur einer Website beschrieben werden, sodass die Websitenavigations-API und die Websitenavigationssteuerelemente eine logische (statt physische) Websitestruktur verfügbar machen können. Wenn Sie das URL-Rewrite-Modul mit einer ASP.NET-Anwendung mit Websitenavigation verwenden, möchten Sie in der Regel, dass die Navigationssteuerelemente gemäß Ihrer logischen Websitestruktur funktionieren, die öffentliche oder virtuelle URLs verwendet.

Sie können z. B. eine Sitemap wie im folgenden Beispiel gezeigt definieren:

<?xml version="1.0" encoding="utf-8" ?>
<siteMap xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0">
  <siteMapNode url="~/Products/" title="Products" description="Products Home Page">   
    <siteMapNode url="~/Products/Hardware/" title="Hardware" description="Hardware Products" /> 
    <siteMapNode url="~/Products/Software/" title="Software" description="Software Products" />
  </siteMapNode>
</siteMap>

Sie können dann Umschreibungsregeln definieren, die die folgenden Umschreibungen ausführen:

  • „/Products/“ in „/Products.aspx“
  • „/Products/Hardware“ in „/Products.aspx?category=Hardware“
  • „/Products/Software“ in „/Products.aspx?category=Software“

Das Definieren einer Sitemap mithilfe dieser virtuellen URLs kann dazu führen, dass die SystemWeb.SiteMap-Klasse nicht ordnungsgemäß funktioniert. Wenn Sie versuchen, auf die SiteMap.CurrentNode-Eigenschaft einer ASP.NET-Seite zuzugreifen, kann die Eigenschaft NULL enthalten. Dies kann dazu führen, dass Websitenavigationssteuerelemente wie SiteMapPath und Menu falsch funktionieren.

Das URL-Rewrite-Modul für IIS enthält ein Update für ASP.NET, das die Navigationssteuerelemente korrigiert, sodass sie mit virtuellen URLs funktionieren, die umgeschrieben wurden. Mit diesem Update verweist die SiteMap.CurrentNode-Eigenschaft auf das SiteMapNode-Objekt, das der aktuell angeforderten virtuellen URL entspricht.

Das Update für ASP.NET gilt nur für .NET Framework 3.5 SP1 und höher. Um das Update zu erhalten, upgraden Sie .NET Framework auf Version 3.5 SP1, und führen Sie dann das Installationsprogramm für das IIS-URL-Rewrite-Modul aus, das auch das ASP.NET-Update installiert.

Verhindern der Umschreibung von Anforderungen für ASP.NET-Webressourcen

ASP. NET-basierte Webanwendungen stellen sehr oft Anforderungen an die Datei „WebResources.axd“, um Assemblyressourcen abzurufen und sie an den Webbrowser weiterzugeben. Auf dem Server ist keine solche Datei vorhanden, da ASP.NET den Inhalt dynamisch generiert, wenn „WebResources.axd“ angefordert wird. Wenn Sie also über eine URL-Umschreibungsregel verfügen, die nur dann eine Umschreibung oder Umleitung durchführt, wenn die angeforderte URL nicht einer Datei oder einem Ordner im Dateisystem eines Webservers entspricht, kann diese Regel Anforderungen an „WebResources.axd“ versehentlich umschreiben und so Ihre Anwendung beschädigen.

Dieses Problem kann ganz einfach verhindert werden, indem Sie der Umschreibungsregel eine zusätzliche Bedingung hinzufügen:

<rule name="RewriteUserFriendlyURL1" stopProcessing="true">
  <match url="^([^/]+)/?$" />
  <conditions>
    <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
    <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
    <!--  The following condition prevents rule from rewriting requests to .axd files -->
    <add input="{URL}" negate="true" pattern="\.axd$" />
  </conditions>
  <action type="Rewrite" url="article.aspx?p={R:1}" />
</rule>