ASP.NET 3.5 SP1: Bug im HyperLink Control bei UrlRewriting
Nachdem ich mir heute den Kopf über die Fehlermeldung:
Vorangestellte .. können nicht zum Beenden auf oberster Verzeichnisebene verwendet werden.
(für die Suchmaschinen hier dann auch noch auf Englisch :)
Cannot use a leading .. to exit above the top directory
zerbrochen und natürlich erstmal die Schuld bei mir gesucht habe, bin ich letztendlich nach langem Suchen dann doch drauf gekommen
[1], dass das ein Bug im ASP.NET HyperLink Control ist.
Leider, leider ist der schon ziemliche lange bekannt
[2] und wurde damals als nicht lösbar klassifiziert. Allerdings war das zu ASP.NET 2.0 Zeiten und die sind ja bekanntlich schon eine Weile her.
Was war passiert?Ein Kunde wollte in einem Menücontrol zusätzlich zum Linktext auch noch ein Bild, welches ebenfalls verlinkt werden sollte. Nichts leichter als das, wozu gibt's <asp:HyperLink ... ImageUrl="~/Images/Bild.jpg" />?
Tja, leider kamen da noch einige andere Änderungen dabei, die dann auch gleich eingebaut wurden und so bin ich natürlich nicht gleich darauf gekommen, dass am HyperLink Control, bzw. dem ImageUrl Attribut liegen könnte, insbesondere, da das zum einen sowas banales ist, dass man nicht im Traum daran denkt, dass das nicht funktionieren würde und andererseits eine andere Website, die auf dem gleichen CMS aufbaut, weiterhin problemlos läuft (zugegebenermaßen ist obiges Konstrukt dort zu nicht finden, was mir aber halt leider nicht so ins Auge gefallen ist).
Normalerweise kommt die o.g. Fehlermeldung, wenn man bspw. mit ../ oder ähnlichem referenziert. Hab ich aber nicht (außer in externen CSS Dateien, die sollten aber eigentlich nicht vom IIS geparst werden). Also ging die Suche los.
Anleitung zum Reproduzieren des Bugs 1. Man setze eine IIS Website (IIS 6 oder 7) auf. Kein Unterordner, kein virtuelles Verzeichnis, wirklich eine eigene Website). Im ASP.NET Development Webserver könnte es sein, dass es funktioniert, hab ich aber nicht probiert.
2. Man baue ein ASP.NET 3.5 Testprojekt auf, welches auf die neu erstellte Website im IIS zeigt.
3. Man nehme ein UrlRewriting Modul, welches den Request auf "/Produkte/123.aspx" bspw. mittels:
HttpContext.Current.RewritePath( "~/Produkte.aspx?Product=123", False )
umbiegt. Wichtig dabei ist, dass man nicht auf demselben Ordner bleibt, sondern einen (nicht vorhandenen) Unterordner (im Beispiel "Produkte") aufruft, da dann die ASP.NET Engine die Pfade umschreiben muss, da sich der interne Pfad vom eigentlich angeforderten unterscheidet.
4. Man baue ein HyperLink Control mit gesetztem ImageUrl Attribut in eine Webform oder ein Control ein.
<asp:HyperLink ID="MyDoofesHyperLinkControl" runat="server" ImageUrl="~/Images/Bild.jpg" NavigateUrl="~/Ordner/Datei.aspx" />
5. Man lasse das ganze laufen.
6. Man "erfreue" sich an der Fehlermeldung.
(Falls ich die Zeit finde, poste ich in den nächsten Tagen noch ein Beispielprojekt, mit dem man das Ganze reproduzieren kann).
Die Lösung ist (wenn man sie kennt) relativ simpel. Man verwendet einfach kein HyperLink Control bzw. dessen ImageUrl Eigenschaft, wenn man mit UrlRewriting arbeitet, sondern trennt hier in ein HyperLink- und ein Imagecontrol.
<asp:HyperLink ID="MyDoofesHyperLinkControl" runat="server" NavigateUrl="~/Ordner/Datei.aspx">
<asp:Image ID="MyKlugesImageControl" runat="server" ImageUrl="~/Images/Bild.jpg" />
</asp:HyperLink>
Abschliessende Worte
Ehrlich gesagt, find ich es schon ziemlich "komisch", dass ein solcher Bug (und um nichts anderes handelt es sich hier, da gibts keine "by design" oder "feature" Ausrede) nicht zumindest in der neuen Version gefixt wurde. Die Aussage, aus Kompatibilitätsgründen würde das nicht gehen, kann ich nicht nachvollziehen. Alternativ würde eine entsprechend aussagekräftige Fehlermeldung, die das Problem besser beschreibt, auch schon mal helfen, dass man sich keinen Wolf nach möglichen, eigenen Fehlern sucht.
[1]
http://pietschsoft.com/post/2007/10/ASPNET-RewritePath-breaks-HyperLinks-ImageUrl-in-App_Theme-file-when-path-with-slash-is-rewritten.aspx[2]
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=235385