Zur generellen Bearbeitung von beim Frontend-Server eintreffenden Anforderungen.

Ziel: Alle Aufrufe werden systematisch und vollständig abgearbeitet und eine passende Antwort schnellst­möglich zurückgesendet - es sei denn, der Aufruf ist unerwünscht und soll ausgebremst etc. werden.

Randbedingungen: Es werden nur GET-Aufrufe erwartet, HEAD-Aufrufe wwrden (zumindest vorläufig) wie GET behandelt; das Script wird zunächst in Perl implementiert und dann nach PHP übertragen, damit es auch auf sehr preisgünstigen Servern laufen kann.

1. Die mit dem Request gesendeten Parameterwerte (QUERY) werden ausgewertet und für die spätere Verwendung bereitgestellt. Folgende Parameter können angegeben sein:
   • ...
   • redirected: Die Liste der URLs, von denen ein redirect durchgeführt wurde. Diese Angabe sollte dafür genutzt werden, überlastete bzw. nicht aktionsfähige Projektserver unter anderen URLs zu erkennen und denen für eine Weile keine Requests weiterzuleiten.
   • show: Angabe der Spezifikation eines Objektes, dessen Repräsentation als XHTML-Dokument zurückgesendet werden soll.
2. Die /data/config.xds -Datei wird eingelesen und bedarfsgetrieben nach und nach die benötigten Daten (und aus Performancegründen unter Vermeidung der Nutzung von XML-Bibliotheken) per RegExp herausgeholt. Dabei ist zu beachten, dass die Parameterwerte entweder als Attribut-Werte oder als Element-Inhaltstexte zu finden sind.
3. Zunächst wird geprüft, ob die Requestor-IP-Adresse speziell behandelt werden muss:
   • Falls ein Hack etc. vermutet wird, wird der Request ausgebremst und nach einer Wartezeit ein Fehlerstatus zurückgeschiickt.
   • Suchmaschinen-Roboter-Anfragen werden NICHT speziell behandelt.
   • Zukünftig: Zu jeder IP-Adresse wird in einer DB vermerkt, wann der letzte Aufruf stattfand und wieviel Zeit seit dem vorletzten Aufruf vergangen ist. Bei zu hoher Aufruffrequenz wird die Bearbeitungszeit künstlich durch eine Pause verlängert.
     Übereifrige Bots sollen so gebremst werden. Ob sich DoS-AAttacken hiermit wirksam ausbremsen lassen, bleibt jedoch abzuwarten.
   Falls der Request "ausgebremst" etc. wird, wird seine Bearbeitung abgeschlossen. Ansonsten wird weiter gemacht:
4. Falls aus der config.xds herausgelesen wird, dass der Service derzeit nicht genutzt werden kann oder soll(te), werden entsprechende Antworten an den Requestor zurückgeschickt und die Bearbeitung beendet. Folgende Möglichkeiten stehen offen:
   • Es wird ein Redirect zurück gesendet und dabei in der Verweis-URL im Parameter "redirected" die eigene URL sowie ggf. weitere bereits zuvor zum Redirect verwendete URLs in der Liste angegeben.
   • Es sollte zwischen temporärer und langfristiger Weiterleitung unterschieden werden können.
   Nach einem Redirect wird die Request-Bearbeitung abgeschlossen.
5. Das Default- (Perl- bzw. PHP-) Script liest das Grundgerüst für die an den Client (oder den Suchmaschinen-Roboter oder ...) zurückzusendende XHTML-Datei aus der Datei /cgi-bin/future/test/boot-template.xhtml (oder Äquivalent bei anderen Versionen/Releases) ein.
   => Hier könnte ein Perl-Bibliotheksmodul mit der entsprechenden Directories-Suchliste hilfreich sein, die auch das Script für die Umwandlung in das zu versendende Dokument - anstelle der explizit per Script abzuarbeitenden Quellenliste - sein.
6. Beim Boot-Template werden anhand diverser Parameterwerte Ersetzungen vorgenommen:
   • Der Projekt-Name wird an allen mit {{project-name}} gekennzeichneten Stellen ersetzt.
   • Anhand der Angaben zur gewünschten (NIcht-)Script-Komprimierung wird der Link zur ausgewählten Script-Variante aufgesetzt (voll komprimiert, ohne Kommentare oder unkomprimiert oder ggf. weitere Varianten). {tbd: Exaktere Angaben}
   • Die Links zu den zugehörigen Komponenten-Bibliotheken werden aufgesetzt. {tbd: Exaktere Angaben}
     Sarissa ist baldmöglichst auszumustern.
7. Wenn im QUERY-Parameter eine ?show=ObjId -Anforderung enthalten ist und das so bezeichnete Objekt frei veröffentlicht werden darf, das vorbereitete Darstellungsfragment des Objektes an der dafür vorgesehenen Stelle der der Boot-Datei einfügen. Die Fragmente stehen im Verzeichnis /uncomplicated/ und werden dort automatisiert auf Stand gehalten.
   Ansonsten: Falls ein Default-Objekt angegeben ist, dessen Darstellungsfragment einbetten.
   Ansonsten das vorbereitete Fragment für die Startseite des Projektes einbetten. Dabei wird der für die Objektdarstellung verwendete Navigations-Teil der Boot-Vorlage ersetzt.
   Anmerkung: Diese Einbettungen werden beim Client sofort auf "unsichtbar" gesetzt, falls dort Scripting verfügbar ist. Falls danach das Hochfahren des Client-WIM-Systems scheitert, wird das eingebettete Fragment wieder sichtbar geschaltet. Ergänzt durch einen Hinweis auf die "Browser-Unfähigkeit", die aber nicht für Suchmaschinen-Bots sichtbar sein sollte (windows.write verwenden ?)
8. ...

... tbd ...

Aufgaben des Frontend-Servers bez. der Clients

Die Vorlage-Datei für das Boot-Dokument

Die config.xds -Datei