Wir sind derzeit bei der Recherche und Installation unserer neuen Firmenseite www.teamaton.com und mehreren Blogs, die wir dort betreiben wollen. Uns bietet sich hier eine All-in-one-Lösung wie Orchard an, mit der wir sowohl unsere Firmenseite pflegen als auch unsere Blogs hosten und verwalten können.
Eine Anforderung, die wir darüber hinaus erfüllen wollen, ist der Zugriff auf unsere Blogs über firmenunabhängige Adressen. Hat man einmal seinen eigenen, evtl. auch Multi-User-Blog aufgebaut und eine kleine Community um ihn versammelt, schmerzt ein Umzug auf eine neue Adresse sehr, vor allem, wenn man über die alte Domain nicht mehr verfügt und so keine Weiterleitung einrichten kann. Um einem solchen Problem in Zukunft vorzubeugen, sollen unsere Blogs, die beispielsweise bei Orchard über eine einen virtuellen Unterordner erreichbar sein, über je eine eigene Adresse erreichbar sein.
In diesem Blogpost will ich beschreiben, wie ich dies im IIS 7 auf einem Windows Web Server 2008 R2 konfiguriert habe und welche Weg nicht zum Ziel führ(t)en.
In unserem Fall wollen wir zuerst unseren Design-Blog, den wir in unserer Orchard-Installation unter blogs.teamaton.com/design angelegt haben, unter www.friendly-fox.com zugänglich machen. Dabei wollen wir keine Redirects verwenden – der Nutzer soll sich unabhängig vom Hosting immer auf friendly-fox.com wähnen. Also benötigen wir eine Rewrite-Lösung. Das URL-Rewrite-Module für den IIS, das mittlerweile in Version 2 vorliegt, bietet sich hierfür an. Wenn man es von o.g. Seite – am einfachsten per WebPI (Web Platform Installer) - installiert hat, sieht man das Modul in der Site-Übersicht in der Kategorie IIS:
Mein erster Versuch ging nun in die Richtung, eine Rewrite-Regel direkt hier auf der Site zu definieren. Ich wollte die URL friendly-fox.com auf blogs.teamaton.com/design umschreiben. Also habe ich dort eine neue Regel für diesen Rewrite angelegt (siehe nächster Screenshot). Aber so richtig Sinn macht die Regel an der Stelle nicht, denn:
- Damit diese Website überhaupt den Request für friendly-fox.com zur Verarbeitung bekommt, muss ich ein Binding für friendly-fox.com anlegen.
- Das neue Binding führt aber dazu, dass nun die komplette Seite blogs.teamaton.com unter friendly-fox.com erreichbar ist, was wir nicht wollten.
- Die Weiterleitung hat nicht funktioniert.
Der nächste Ansatz war dann, die Rewrite-Regel auf dem IIS selbst anzulegen, so dass dieser die Anfrag nach friendly-fox.com mit den Inhalten von blogs.teamaton.com/design beantwortet. Dazu habe ich eine Regel auf dem Root-Knoten angelegt:
Leider führte diese Einstellung letztendlich zu einem Redirect statt einem stillen Rewrite, so dass auch diese Option wegfiel.
Nach einer weiteren Recherche im Netz stieß ich auf den lesenswerten Artikel 10 url rewriting tips and tricks, in dem Punkt “7. Reverse Proxy To Another Site/Server” ziemlich genau beschreibt, was ich machen will. Überrascht hat mich, dass unser Szenario mit dem URL-Rewrite-Module allein anscheinend nicht zu lösen ist – wir benötigen dafür zusätzlich das Application Request Routing (ARR) Module. Mit dem WebPI ist die Installation aber ein Kinderspiel, alle Abhängigkeiten werden automatisch mit installiert:
Nach der Installation des ARR-Module muss man entsprechend o.g. Punkt 7. die Checkbox “Enable proxy” aktivieren. Mit dieser Option soll nun der ursprüngliche Request an friendly-fox.com durch einen Proxy (im ARR) an blogs.teamaton.com/design weitergeleitet werden. Das Modul findet man nach einem Klick auf den Root-Knoten im IIS-Manager-Baum:
Nach einem Doppelklick im nächsten Fenster setzt man dann die Checkbox:
Eigentlich hätte ich jetzt schon erwartet, dass die Weiterleitung funktionieren würde. Aber beim Aufruf von http://friendly-fox.com bekomme ich nur die IIS-Willkommensseite zu sehen:
Aus irgendeinem Grund klappt der Match auf ^(www.)?friendly-fox.com/$ nicht. Es gibt dafür aber einen Workaround, indem man zuerst einmal auf .* matcht und dann in einer eigens definierten Condition den eigentlichen Match definiert:
Hier die erste Regel noch mal in der Übersicht des IIS:
Jetzt funktioniert die Weiterleitung inkl. aller Unterdateien (Styles etc.), jedoch sind die Links auf der Seite noch anzupassen. Das sollte sich in einem nächsten Schritt mit Hilfe einer “Outbound Rule” erledigen lassen. Aber das in einem nächsten Post.
Happy Coding, Oliver