031.3 Lektion 1

Die erste Phase eines HTTP-Datenaustauschs zwischen Client und Server wird vom Client initiiert, indem er eine Request-Nachricht an den Server sendet. Nehmen wir als Beispiel eine Standardaufgabe eines Browsers: das Laden einer HTML-Seite von einem Server, auf dem eine Website wie https://learning.lpi.org/en/ gehostet wird. Die Adresse, oder URL, enthält mehrere relevante Informationen — in diesem Beispiel sind es die drei folgenden:

Hat der HTTP-Server die Kopfzeile der Request-Nachricht erhalten, sendet er eine Antwortnachricht an den Client zurück. Eine HTML-Datei-Anfrage hat normalerweise einen Antwort-Header wie diesen:

In der ersten Zeile steht die Version des HTTP-Protokolls, die in der Antwortnachricht verwendet wird und die der Version im Request-Header entsprechen muss. Dann, ebenfalls in der ersten Zeile, erscheint der Statuscode der Antwort, der angibt, wie der Server die Antwort auf die Anfrage interpretiert und erzeugt hat.

Der Statuscode ist eine dreistellige Zahl, wobei die äußerste linke Ziffer die Antwortklasse angibt. Es gibt fünf Klassen von Statuscodes, die von 1 bis 5 nummeriert sind und jeweils eine Art der vom Server durchgeführten Aktion angeben:

Die zweite und dritte Ziffer werden verwendet, um zusätzliche Details anzugeben. Der Code 200 bedeutet beispielsweise, dass die Anfrage ohne Probleme beantwortet werden konnte. Wie im Beispiel gezeigt, kann auch eine kurze Textbeschreibung auf den Antwortcode (OK) folgen. Einige spezifische Codes sind von besonderem Interesse, um sicherzustellen, dass der HTTP-Client in ungünstigen Situationen auf die Ressource zugreifen kann, oder um im Falle einer erfolglosen Anfrage den Grund für das Scheitern zu ermitteln:

Obwohl sie aussagen, dass die Anfrage nicht bearbeitet werden konnte, zeigen die Statuscodes 4xx und 5xx zumindest an, dass der HTTP-Server läuft und in der Lage ist, Anfragen zu empfangen. Die 4xx-Codes erfordern eine Aktion auf dem Client, weil seine URL oder seine Anmeldedaten falsch sind. Im Gegensatz dazu deuten die 5xx-Codes auf einen Fehler auf der Serverseite hin. Im Zusammenhang mit Webanwendungen zeigen diese beiden Klassen von Statuscodes daher an, dass die Fehlerquelle in der Anwendung selbst liegt, entweder im Client oder im Server, und nicht in der zugrunde liegenden Infrastruktur.

HTTP-Server verwenden zwei grundlegende Mechanismen, um den vom Client angeforderten Inhalt zu liefern. Der erste Mechanismus liefert statische Inhalte, d.h. der in der Request-Nachricht angegebene Pfad entspricht einer Datei im lokalen Dateisystem des Servers. Der zweite Mechanismus liefert dynamische Inhalte: Der HTTP-Server leitet die Anfrage an ein anderes Programm weiter – wahrscheinlich ein Skript –, das die Antwort aus verschiedenen Quellen, wie Datenbanken und anderen Dateien, zusammenstellt.

Obwohl es verschiedene HTTP-Server gibt, verwenden sie alle dasselbe HTTP-Kommunikationsprotokoll und übernehmen mehr oder weniger dieselben Konventionen. Eine Anwendung, die keine besonderen Anforderungen stellt, kann mit jedem herkömmlichen Server wie Apache oder NGINX implementiert werden. Beide sind in der Lage, dynamische Inhalte zu generieren und statische Inhalte bereitzustellen, aber es gibt feine Unterschiede in der Konfiguration der einzelnen Server.

Der Speicherort statischer Dateien, die ausgeliefert werden sollen, ist in Apache und NGINX unterschiedlich definiert. Üblicherweise liegen diese Dateien in einem speziellen Verzeichnis, dessen Name mit dem Host verknüpft ist, zum Beispiel /var/www/learning.lpi.org/. Im Apache wird dieser Pfad durch die Konfigurationsanweisung DocumentRoot /var/www/learning.lpi.org in einem Abschnitt definiert, der einen virtuellen Host beschreibt. Bei NGINX wird die Direktive root /var/www/learning.lpi.org in einem server-Abschnitt der Konfigurationsdatei verwendet.

Welchen Server Sie auch wählen, die Dateien unter /var/www/learning.lpi.org/ werden über HTTP auf fast dieselbe Weise bereitgestellt. Einige Felder in der Kopfzeile der Antwort und ihr Inhalt können zwischen den beiden Servern variieren, aber Felder wie Content-Type müssen in der Kopfzeile der Antwort vorhanden und auf jedem Server konsistent sein.

HTTP wurde so konzipiert, dass es mit jeder Art von Internetverbindung funktioniert, ob schnell oder langsam. Außerdem muss der HTTP-Austausch aufgrund der verteilten Architektur des Internets viele Netzknoten durchlaufen. Daher ist es wichtig, eine Strategie zur Zwischenspeicherung von Inhalten anzuwenden, um die redundante Übertragung bereits heruntergeladener Inhalte zu vermeiden. HTTP-Übertragungen können mit zwei grundlegenden Arten von Caches arbeiten: shared und private.

Ein shared, also gemeinsam genutzter Cache wird von mehr als einem Client verwendet. Ein großer Content Provider könnte beispielsweise Caches auf geografisch verteilten Servern nutzen, so dass Kunden die Daten von ihrem nächstgelegenen Server erhalten. Sobald ein Client eine Anfrage gestellt hat und die Antwort in einem gemeinsamen Cache gespeichert wurde, erhalten andere Clients, die dieselbe Anfrage in demselben Gebiet stellen, die Antwort aus dem Cache.

Einen privaten Cache legt der Client für seine ausschließliche Verwendung selbst an. Dabei handelt es sich um die Art der Zwischenspeicherung, die der Webbrowser für Bilder, CSS-Dateien, JavaScript oder das HTML-Dokument selbst vornimmt, so dass sie nicht erneut heruntergeladen werden müssen, wenn sie in kurzem zeitlichen Abstand angefordert werden.

Sowohl die shared als auch die private Cache-Strategie verwenden HTTP-Header, um zu steuern, wie der heruntergeladene Inhalt zwischengespeichert wird. Beim privaten Cache konsultiert der Client den Response-Header und prüft, ob der Inhalt im lokalen Cache noch mit dem aktuellen Remote-Inhalt übereinstimmt. Ist dies der Fall, verzichtet der Client auf die Übertragung der Nutzdaten der Antwort und verwendet die lokale Version.

Die Gültigkeit der zwischengespeicherten Ressource kann auf verschiedene Weise beurteilt werden. Der Server kann in der Kopfzeile der Antwort auf die erste Anfrage ein Verfallsdatum angeben, so dass der Client die zwischengespeicherte Ressource nach Ablauf der Frist verwirft und sie erneut anfordert, um die aktualisierte Version zu erhalten. Der Server ist jedoch nicht immer in der Lage, das Verfallsdatum einer Ressource zu bestimmen, so dass es üblich ist, das Antwort-Header-Feld ETag zu verwenden, um die Version der Ressource zu identifizieren, z.B. Etag: "606adcd4-46fa".

Um zu überprüfen, ob eine zwischengespeicherte Ressource aktualisiert werden muss, fordert der Client vom Server nur deren Antwortkopfzeile an. Wenn das Feld ETag mit dem der lokal gespeicherten Version übereinstimmt, verwendet der Client den zwischengespeicherten Inhalt erneut. Andernfalls lädt er den aktualisierten Inhalt der Ressource vom Server herunter.

Bei einer herkömmlichen Website oder Webanwendung basieren die Funktionen zur Sitzungssteuerung auf den HTTP-Headern. Der Server kann zum Beispiel nicht davon ausgehen, dass alle Anfragen, die von derselben IP-Adresse kommen, von demselben Client stammen. Die verbreitetste Methode, über die der Server verschiedene Anfragen einem einzigen Client zuordnet, ist die Verwendung von Cookies, einem Identifikations-Tag, das der Server dem Client im HTTP-Header übergibt.

Cookies ermöglichen es dem Server, Informationen über einen bestimmten Client aufzubewahren, auch wenn die Person, die den Client bedient, sich nicht ausdrücklich identifiziert. Mit Cookies ist es möglich, Sitzungen einzurichten, in denen Anmeldungen, Warenkörbe, Präferenzen usw. zwischen verschiedenen Anfragen an denselben Server, der sie bereitgestellt hat, erhalten bleiben. Cookies werden auch verwendet, um das Surfverhalten der Benutzer zu verfolgen — daher ist es wichtig, vor der Übermittlung von Cookies die Zustimmung einzuholen.

Der Server setzt den Cookie in der Kopfzeile der Antwort über das Feld Set-Cookie. Der Wert des Feldes ist ein Name-Wert-Paar, das ein mit einem bestimmten Client verbundenes Attribut darstellt. Der Server kann zum Beispiel eine Identifikationsnummer für einen Client erstellen, der eine Ressource zum ersten Mal anfordert, und diese im Antwort-Header an den Client übergeben:

Wenn der Client die Verwendung von Cookies zulässt, enthalten neue Anfragen an denselben Server das Cookie-Feld in der Kopfzeile:

Mit dieser Identifikationsnummer ruft der Server spezifische Definitionen für den Client ab und erzeugt eine individuelle Antwort. Es sind auch mehrere Set-Cookie-Felder möglich, um verschiedene Cookies an denselben Client zu liefern. Auf diese Weise kann mehr als eine Definition auf der Client-Seite bewahrt werden.

Cookies werfen sowohl Fragen des Datenschutzes als auch potenzieller Sicherheitslücken auf, da sie grundsätzlich an einen anderen Client weitergegeben werden können, den der Server als den ursprünglichen Client identifiziert hat. Cookies, die der Aufrechterhaltung von Sitzungen dienen, bieten möglicherweise Zugang zu sensiblen Informationen des ursprünglichen Clients. Daher ist es sehr wichtig, dass Clients lokale Schutzmechanismen einsetzen, um zu verhindern, dass ihre Cookies unbefugt extrahiert und wiederverwendet werden.