Ein Beispiel

Links von diesem Artikel befindet sich eine Navigation, womit Sie innerhalb dieser Rubrik zwischen den einzelnen Artikeln hin- und herblättern können. Wie wir wissen, wird die Internetverbindung zum Server wegen dem HTTP-Protokoll nach jedem Seitenaufruf getrennt. Das bedeutet mit anderen Worten: in dem Moment, wo Sie diese Seite sehen, besteht keine Verbindung mehr zum Server. Da ist doch die Frage berechtigt, was denn eigentlich geschieht, wenn Sie eine Seite vorblättern, finden Sie nicht?

Die Antwort auf diese Frage ist einfach: der Browser des Surfers schickt eine neue Anfrage an den Server. Dabei wird in der Adresszeile die gewünschte Seitenzahl als Parameter mitgeschickt. Aufgrund von diesem Parameter weiß der Server nun, welche Seite gemeint ist. Der Server liest diese betreffenden Daten ein und liefert sie anschließend in Form von HTML-Quelltext an Ihren Browser aus, der die Seite anzeigt. Daraufhin wird die Verbindung wieder geschlossen.

OK, das leuchtet ein, aber was ist, wenn der Parameter fehlt? Nun, in diesem Fall könnte der Programmierer dem System die Anweisung geben, daß einfach die erste Seite angezeigt werden soll. Aber was ist, wenn ich den Artikel unterbrechen möchte, um ihn später zuende zu lesen? Wäre es nicht schön, wenn sich die Internet-Seite daran erinnern könnte, auf welcher Seite ich stehengeblieben bin? - Das ist in der Tat eine gute Frage.

Damit sich die Internet-Seite daran erinnern kann, auf welcher Seite Sie stehen geblieben sind, müssen Sie sich irgendwie identifizieren. Aber wie ist das möglich, wo doch nach jedem Seitenaufruf die Verbindung getrennt wird? Könnte die Internetseite vielleicht die IP-Adresse des Absenders speichern? Ja, das könnte sie, aber dieser Trick funktioniert nicht, wenn sich mehrere Surfer eine IP-Adresse teilen. Um dieses Problem zu lösen, hat sich die Firma Netscape vor vielen Jahren einen eleganten Trick einfallen lassen.

Das Cookie

Ihr Computer ist ja nur mit dem Internet verbunden, wenn er eingeschaltet ist, resp. wenn Sie sich bei Ihrem Provider eingewählt haben. Eine Internetseite ist dagegen auf einem Computer gespeichert, der ständig mit dem Internet verbunden ist. Denn man will ja, dass möglichst viele Surfer die Internetseite besuchen. Und natürlich wäre es sehr bequem, wenn sich die Internetseite daran erinnern könnte, auf welcher Artikel-Seite die einzelnen Surfer stehen geblieben sind, damit die betreffende Seite bei dem nächsten Besuch wieder angezeigt werden kann. Die Frage ist also, wie kann der Webserver all die Surfer voneinander unterscheiden?

Hierzu hat sich die Firma Netscape vor vielen Jahren etwas Besonderes einfallen lassen: man muss den Browser des Surfers dazu bringen, bei jedem Aufruf eine kleine Datei mitzuschicken, worin eine eindeutige Identifikations-Nr. mitgeschickt wird. Das war die Geburt des berüchtigten Cookies, was auf Deutsch soviel wie "Keks" bedeutet. Aber wie funktioniert solch ein Cookie?

Wenn Ihr Browser bei einem Webserver zum ersten Mal eine Internet-Seite anfordert, generiert der Server in bestimmten Fällen eine eindeutige Identifikations-Nummer und speichert diese irgendwo auf der Festplatte des Servers mit der Information ab, auf welcher Seite der Surfer das letzte Mal gewesen ist. Dann wird diese Identifikations-Nr. in eine kleine Datei gepackt, und für Sie unsichtbar mit dem HTML-Quelltext der gewünschten Internet-Seite mitgeschickt. Das ist das Cookie Ihr Browser zeigt daraufhin die gewünschte Internetseite an und speichert das empfangene Cookie irgendwo auf Ihrer Festplatte.

Wenn Sie nun eine weitere Seite anfordern, prüft Ihr Browser, ob sich die gewünschte Seite auf einem Server befindet, wo Sie sich bereits identifiziert haben. Sollte für die neue Anfrage bereits ein Cookie gespeichert sein, wird dieses mit der neuen Anfrage für Sie unsichtbar an den Server geschickt. Dadurch weiß der Server nun, dass dieser Surfer schon mal eine Anfrage gestellt hat. Der Surfer kann dann nachsehen, auf welcher Seite Sie das letzte gewesen sind, und zeigt diese an.

Das HTTP-Protokoll

Wenn in unserem Beispiel nun auch noch die Frage nach der Sprache (in diesem Fall deutsch) und das Zugriffsrecht (Sie dürfen) geklärt ist, stehen dem System alle notwendigen Parameter zur Verfügung, die gebraucht werden, um die gewünschten Informationen aus der Datenbank oder aus dem Filesystem zu lesen. Jetzt kann der HTML- Quelltext zusammengestellt und an den Browser übergeben werden. - Aber heißt das denn, daß sämtliche Inhalte und Daten bei jedem Seitenaufruf neu eingelesen werden müssen? - Ja, genau das tut ein klassisches CMS! - Wir kommen der Sache langsam auf die Spur.

Auch wenn moderne Server längst Mittel und Wege gefunden haben, Datensätze und Quelltexte eine Zeit lang im Speicher aufzubewahren (im Cache), hat sich an der oben beschriebenen Logik nichts geändert. Das bedeutet: wir Programmierer müssen die gesamte Logik einer Internet-Anwendung stets vor jedem einzelnen Seitenaufrufe packen. Wir können dem Server nicht mitteilen: "während der Surfer mit Lesen beschäfigt ist, tu das und das." oder "wenn das und das geklickt wurde, ergänze die Seite mit zusätzlichen Informationen". Das geht nur, wenn man das Protokoll mit anderen Technologien ergänzt, wie z.B. Ajax. Schuld daran ist das HTTP-Protokoll, welches besagt, dass jede Verbindung unmittelbar nach der Beantwortung wieder beendet werden muss.

In diesem Kontext stellt sich natürlich die Frage, weshalb wir denn nicht einfach ein anderes Protokoll verwenden? - Dazu sollte man wissen, daß es durchaus Sinn macht, die Verbindung nach jedem Seitenaufruf zu beenden. Denn auf diese Weise ist die Verbindung zwischen dem Server und dem Browser nie besetzt. Das ist aber nicht der eigentliche Grund, weshalb wir das HTTP-Protokoll verwenden, denn es gibt inzwischen Alternativen, die tatsächlich sehr viel besser sind. Der Hauptgrund besteht tatsächlich nur darin, daß sich dieses Protokoll weltweit als Standart durchgesetzt hat.

Der HTML-Overhead

Ein weiterer Standart ist die Formatierungssprache HTML. Wenn man sich den HTML-Quelltext einer Internet-Seite etwas genauer ansieht, wird man schnell feststellen, daß der Quelltext nicht nur aus Informationen besteht, die man im Browser sehen kann, sondern auch aus einer Vielzahl von Informationen, die man nicht sehen kann. Ich nenne das den HTML-Overhead. Da gibt es z.B. sogenannte Metatags, womit man den Browsern oder den Suchmaschinen Anweisungen geben kann, wie sie mit der Seite umzugehen haben. Im Quelltext können zudem Formatierungs-Anweisungen (Stylesheets) oder gar ganze Programme versteckt sein (Javascript, DHTML, Ajax). Manchmal beinhaltet eine HTML-Seite soviele Overhead, daß der sichtbare Teil tatsächlich nur nur den kleinsten Teil der übermittelten Daten ausmacht.

Die Frage, die sich hier stellt, ist natürlich: woher weiß der Server denn, welche Zusatz-Informationen im Quelltext stehen sollen? - Auch diese Antwort ist einfach: man muß es dem Server irgendwann einmal mitgeteilt haben! Das bedeutet, wenn ich einen professionellen HTML-Quelltext erstellen möchte, muß ich mir die Mühe machen, auf dem System eine große Anzahl von Einstellungen vorzunehmen. Dabei gilt, je anspruchsvoller eine Seite ist, desto umfangreicher sind diese Einstellungen. Und je mehr Einstellungen, desto mehr HTML-Kenntnisse benötigen Sie. Kompliziert, nicht wahr?

Fassen wir das alles zusammen: Ein CMS setzt einzelne Internet-Seiten wie ein Puzzle zusammen. Dabei werden nicht nur Texte und Bilder zusammengefügt, sondern auch eine relativ große Anzahl von Zusatzinformationen. Dabei ist es völlig gleichgültig, ob das CMS die HTML-Seiten in Echtzeit zusammenstellt, oder ob das CMS die HTML-Seiten für den späteren Zugriff vorbereitet.

weiter zur nächsten Seite »