Die Idee Die ersten Versuche RedirectNow Redirector Quick Edition Der Durchbruch: Redirector 2.0 Die Probleme von JavaScript
Startseite --> Projekte --> Redirector --> Geschichte des Redirector
Die Idee
Die ersten Versuche
RedirectNow
Redirector Quick Edition
Der Durchbruch: Redirector 2.0
Die Probleme von JavaScript
Die Idee zum Redirector kam mir, als mir immer öfter Verweise auf eine geheimnisvolle Datei namens redir.dll (eine ISAPI-Anwendung) auf dem Microsoft-Server auffielen. Da wird ein ellenlanger Query String übergeben, und schon wird der Besucher auf eine neue Adresse umgeleitet.
Lange habe ich nach einem Sinn dahinter gesucht, als es mir plötzlich einfiel: Das Problem der "Deadlinks" soll vermieden werden. Microsoft ändert seine Seite ständig, und da ist so etwas nötig, um die Besucher nicht auf nicht mehr existierende Seiten zu verweisen.
Ich war dermaßen fasziniert davon, dass ich für meine Seite auch so etwas haben wollte. Es sollte viel Zeit vergehen, bis der "patShaping Redirector" seinem großen Vorbild einigermaßen ähnlich sein sollte.
Ich machte mich daran, ein kleines JavaScript-Programm zu schreiben, dass auch Variablen verarbeiten und anschließend eine neue Adresse laden kann.
Die erste Fassung des Redirector war mehr als spartanisch. Er bestand lediglich aus einer einzelnen Datei namens redirect.js, die eine Funktion namens redirect() bereitstellte. Die Datei redirect.js konnte in HTML-Dateien eingebunden werden. Die auf diese Weise in den HTML-Dateien zur Verfügung stehende Funktion redirect() konnte nun durch einen JavaScript-Link (ein Link, der das Pseudo-Protokoll javascript: verwendet) angesprochen werden und auch Parameter entgegennehmen. Das Skript prüfte, ob es für die Variable eine Adresse gab und rief die entsprechende Adresse auf.
Dieses Prinzip war zwar einfach und zuverlässig, aber nicht das, was ich wollte. Ich wollte unbedingt, dass der Redirector so zu bedienen ist, wie Microsofts redir.dll.
Die Lösung für das Problem sah ich, als mir in den Hilfe-Dateien einiger Programme der Firma DSB Associates, Inc. Verweise auffielen, die ebenfalls Parameter an eine HTML-Datei übergaben.
Nachdem ich es etliche Male vergessen hatte, sah ich mir die Datei fwbugs.htm, an die Parameter übergeben wurden, mal an. Ich verstand ehrlich gesagt nicht, was die Datei mit dem Query String machte. Aber es schien zu funktionieren, also wollte ich das JavaScript-Programm, das sich in dieser Datei befand, haben.
Als nächstes kontaktierte ich den Autor dieser Datei, Martin E. Haring. Bevor ich mir dieses Skript kopierte, wollte ich lieber den Autor kontaktieren, weil ich Ärger vermeiden wollte.
Haring hatte zunächst nicht verstanden, was ich eigentlich meinte. Er dachte, ich hätte Interesse an den Perl-Skripten, an die fwbugs.htm seine Daten sendet. Nachdem ich ihm aber erklärte, was ich meinte, willigte er ein und ich durfte den JavaScript-Code aus fwbugs.htm verwenden.
Nach etwas Arbeit war RedirectNow geboren. Es bestand aus dem Kern und der Maschine. Der Kern befand sich in einer Datei namens RedirectNow.js und die Maschine in der Datei machine.htm. Beide Teile waren miteinander verbunden. Die Maschine konnte, wie redir.dll, einen Query String entgegennehmen. Der Kern hat den Query String geparst und eine entsprechende Adresse aufgerufen.
RedirectNow ist eigentlich nie an die Öffentlichkeit getreten. Es war ein kleiner Dienst, versteckt in den Tiefen der patShaping-Seiten.
Doch RedirectNow hatte einen großen Nachteil: Es war ein eigenständiges Programm, das vom Redirector unabhängig war. Ihm standen nicht dieselben Variablen und Adressen zur Verfügung wie dem eigentlichen Redirector. Außerdem standen RedirectNow nur wenige der Variablen des eigentlichen Redirector zur Verfügung. Welche das genau waren, lässt sich leider nicht mehr feststellen.
Also entstand Redirector Quick Edition. Es vereinigte den normalen Redirector und RedirectNow in sich. Eine Verschmelzung der beiden Programme war das nicht direkt, da Redirector Quick Edition komplett neu programmiert wurde. Und zwar ohne Fremdhilfe (außer vielleicht SELFHTML)!
Es tat nichts weiter, als den Query String, den es übermittelt bekam, zu prüfen, ihn auseinanderzunehmen und anschließend den ermittelten Wert an die Funktion redirect() zu übergeben.
Um Abwärtskompatibilität herzustellen wurde die Datei, die einst die Maschine von RedirectNow war, umprogrammiert. Die Maschine leitete eventuelle Anfragen an Redirector Quick Edition weiter.
Es gab aber immer noch ein Problem: Redirector Quick Edition konnte sich nicht selbst aus der Browser-History löschen, da die Funktion redirect(), auf die es zugreift, einfach nur eine neue Adresse lädt und sonst nichts.
Es musste ein neues Konzept her: Dieses Mal wurde der Redirector in drei einzelne Funktionen aufgeteilt: redirect(), quick() und getadr(). Die wichtigste der Funktionen war getadr(). Sie ordnet den Variablen entsprechende Adressen zu. Diese Funktion kann Werte entgegennehmen, versucht eine Adresse zuzuordnen und liefert die Adresse in Form der Variable adr zurück. quick() wird von Redirector Quick Edition verwendet. Es übergibt eine Variable an getadr(). Anschließend lädt quick() die neue Adresse und löscht quick.htm aus der Browser-History. Die Funktion redirect() arbeitet genauso, nur dass es keine Adressen aus der Browser-History entfernt, sondern einfach nur die zurückgelieferte Adresse lädt.
Insgesamt lässt sich sagen, dass der Versionssprung gerechtfertigt war.
Etwa fünf Monate nach dem Erscheinen des Redirector 2.0, und zwar am 26.4.2002, erschien die Version 2.1. Sie enthielt eine eigentlich kaum spürbare Verbesserung. Ob das wirklich eine Verbesserung war, weiß ich nicht. Die Verbesserung gab mir einfach ein besseres Gefühl.
Doch ein Problem hatte der Redirector immer noch: Er war in JavaScript programmiert, und dadurch lief die Verarbeitung clientseitig ab. Sollte nun ein Anwender, dessen Browser JavaScript nicht unterstützt oder es aus Sicherheitsgründen deaktiviert wurde, auf einen Link klicken, der den Redirector startet, bekommt der Anwender nur eine Meldung, dass JavaScript nicht funktioniert und der Redirector nicht arbeiten kann.
Also musste eine neue Lösung her: Die Verarbeitung muss serverseitig stattfinden. Hierfür kommen Sprachen wie Perl oder PHP zum Einsatz. Es gab dafür erste Ansätze, die ähnlich programmiert waren wie der Redirector 2.0. Doch es gab ein weiteres Problem: Der Anbieter Tripod, bei dem die patShaping-Seiten früher gehostet waren, erlaubte bis vor einiger Zeit keine serverseitigen Skripte. Doch irgendwann hat man dann PHP erlaubt.
Irgendwann stand dann ein anständiges Konzept für den Redirector 3.0 fest, dass auch mit wenig Aufwand umgesetzt werden konnte. Das Konzept stand übrigens schon vor dem Erscheinen des Redirector 2.1 fest! Die Grundlage für dieses Konzept stammt aus dem PC Magazin, Ausgabe 4/2001.
Der Redirector 3.0 verwendet nur noch das Prinzip von redir.dll, RedirectNow und Redirector Quick Edition. Von der allerersten Methode habe ich mich verabschiedet. Durch die serverseitige Verarbeitung funktioniert es nicht mehr. Es war eigentlich sowieso sinnlos. Dieses Prinzip war nur eine Notlösung aus Tagen, an denen ich mich noch nicht so gut mit JavaScript usw. auskannte.
An dieser Stelle möchte ich noch einen peinlichen Zwischenfall erwähnen, der 8 Tage vor der geplanten Veröffentlichung des Redirector 3.0 (1.6.2002), und zwar am 24.5.2002, geschehen ist:
Ich hatte aus Versehen, als ich erste Vorbereitungen für den damals anstehenden Umbau der patShaping-Seiten treffen wollte, das Verzeichnis, das den Redirector 3.0 enthielt, gelöscht! Zuerst schien es so, als ob die ganze Arbeit umsonst war. Glücklicherweise konnte ein großer Teil des Redirector 3.0 durch ein Undelete-Programm wiederhergestellt werden. Die wichtigsten Daten waren unversehrt! Zerstört waren die Dateien mit den Fehlermeldungen, der Index dieses Abschnittes (es kann auch sein, dass ich ihn lediglich übersehen habe) und ein Teil dieser Datei. Aber auch das Verlorene konnte (so gut wie es ging) rekonstruiert werden.
Startseite --> Projekte --> Redirector --> Geschichte des Redirector
