HTTP - Das Protokoll des Web
Willemers Informatik-Ecke
HTTP (Hypertext Transfer Protocol) ist das Protokoll des World Wide Webs. Übertragen werden vor allem Dokumente, die in HTML kodiert sind.

Der Standardport ist 80. Die Übertragung erfolgt unverschlüsselt. Die aktuelle Version von HTTP/2 und ist in RFC 7540 definiert.

Als verschlüsselte Variante steht HTTPS zur Verfügung, die standardmäßig den Port 443 verwendet.

Das Protokoll HTTP

Das Protokoll ist textbasiert. Das bedeutet, dass die Anfragen (Request) und Antworten (Response) im Klartext über die Leitung gehen.

Das Protokoll ist grundsätzlich statuslos. Das bedeutet, dass eine Sitzung nach der Antwort durch den Server endet. In seiner ursprünglichen Anwendung für den Austausch wissenschaftlicher Dokumente war das völlig ausreichend. In Zeiten von Online-Shops sind aber längere Sitzungen erforderlich. Das heißt, dass der Server mehrere Anfragen einem Client zuordnen können muss. Dies wird beispielsweise über Cookies realisiert.

Die URL

Eine URL besteht aus dem Hostname (oder dessen IP-Adresse) und durch einen Schrägstrich getrennt das gewünschte Dokument, das ggf. durch einen Pfad spezifiziert wird. Optional kann durch einen Doppelpunkt angehängt ein Port spezifiziert werden.

Leerzeichen und Sonderzeichen dürfen in der URL nicht auftreten. Werden sie in den Parametern dennoch benötigt, werden Leerzeichen beispielsweise durch %20 dargestellt. Andere Zeichen werden durch eine URL-Codierung umgesetzt, die von der Zeichencodierung abhängig ist.

HTTP Request-Methoden

Das HTTP-Protokoll kannte in der Version 1.0 die Befehle GET, HEAD und POST. Die Version 1.1 brachte noch PUT und DELETE hinzu.

Aufbau eines HTTP-Befehls

Eine Request beginnt mit der Zeile des Befehls. Beispielsweise lautet diese für einen GET der Datei index.htm folgendermaßen:
GET /index.htm HTP/1.1
Der Aufbau ist:
Befehl Leerzeichen URL Leerzeichen Version CR+LF

Alle Zeilen des Befehls werden mit CR-LF abgeschlossen.

Der Befehl GET besitzt nur einen HEAD, keinen BODY. Darum müssen eventuelle Parameter in der URL untergebracht werden. Das hat zur Konsequenz, dass diese Parameter nicht verschlüsselt werden können.

Der Head enthält allerdings durchaus weitere Informationen. Darin steht beispielsweise der Browser (User-Agent) oder die Sprache, die der Client bevorzugt (Accept-language). Durch einen Doppelpunkt getrennt werden die Inhalte übermittelt.

GET-Anfrage

Der Client sendet zunächst eine Befehlszeile mit dem folgenden Aufbau an den Server: Der Request-Header der GET-Anfrage übermittelt folgende Informationen an den Server: Im Anschluss an das Senden der Anfrage, wartet der Client auf die Antwort des Servers.

POST-Anfrage

Eine POST-Anfrage folgt der gleichen Struktur wie eine GET-Anfrage. Allerdings sendet POST keine Parameter per URL. Die Parameter werden im Message Body (Payload) transportiert. Die GET-Anfrage ist dafür gedacht, Anfragen zu stellen, die keine Änderungen an den Server-Ressourcen verursachen. Die Parameter beschreiben lediglich die angeforderten Daten. POST-Parameter sind dafür gedacht, Server-Ressourcen zu ändern.

HTTP Response

Die erste Zeile der Antwort des Server ist der Status-Code. Er folgt dem Aufbau:
Protokoll Leerzeichen Nummer Leerzeichen Status CR+LF
Beispielsweise ist eine positive Antwort:
HTTP/1.1 200 OK

HTTP-Status-Codes

Der Server antwortet auf Anfragen mit einem Status-Code in Form einer dreistelligen Zahl.
Basis Zahlencode Bedeutung
1xx Informativ
2xx Erfolgreich
200 OK
201 Created
202 Accepted
204 No Content. Anfrage ok, aber kein neuer Inhalt
3xx Es sind weitere Aktionen erforderlich
300 Mehrere Auswahlmöglichkeiten
301 Permanent auf anderer URL
302 Temporär auf anderer URL
304 Inhalt ist unverändert
4xx Fehler des Client
400 Fehlerhafte Anfrage, etwa ungültige URL
401 Nicht authorisiert
403 Verboten
404 Nicht gefunden
5xx Fehler des Servers
500 Interner Serverfehler
501 Nicht implementiert
502 Falsches Gateway (Proxy-Anwendung)
503 Server ist überlastet
505 HTTP-Version nicht unterstützt

Die Headerzeilen liefern zusätzliche Informationen wie Webserver (Server) und dessen Version.

Nach dem Header folgt der eigentliche Dateninhalt, die sogenannte Payload. Auf einen GET ist dies typischerweise ein HTML-Dokument.

Das HTTP-Paket

Unterschiede zwischen HTTP/1.0 und 1.1

HTTP/1.1 erlaubt mehr als 1 Objekt pro Anfrage und stellt damit den Übergang von non-persistent nach persistant dar.

HTTP/1.1 ermöglicht Caching. Der Server meldet modified contents über ein ETag (Beispielsweise x234dff) und max-age (beispielsiweiese (max-age=120). Wendet sich der Client mit der gleicher ETag innerhalb der max-age, meldet sich der Server mit dem Status 304 ohne Payload.

Authentifizierung

Wenn Sie in einem Verzeichnis Ihrer Web-Präsenz die Datei .htaccess hinterlegen, können Sie eine Anmeldung des Benutzers erzwingen.

Es erscheint eine Dialogbox, die Benutzername und Passwort erfragt und mit der in der .htaccess hinterlegten Passwortdatei abgleicht. Jene legt auch fest, auf welche Art (AuthType) kommuniziert wird.

Digest Access Authentication

RFC 2069, 2617, 7235

Ablauf

Der Browser hat eine Seite mit GET angefordert, die in der Datei .htaccess durch eine Digest Authorisation geschützt ist. Darin liegt das durch die Hashfunktion md5 verschlüsselte Passwort und der Benutzer im Klartext vor.

  1. Der Server antwortet mit einer i401-Unauthorized-Antwort. Darin übermittelt er eine nonce, eine zufällige Zahl, die nur einmal verwendet wird.
  2. Der Client ermittelt einen Hashwert (MD5) aus Benutzer, nonce und Passwort.
  3. Der Server prüft, ob das Passwort zu dem hinterlegten passt.

Web Caching

Erweiterung durch HTTP 1.1.

Der Browser speichert zuvor angefragte Seiten mit ihrem letzten Zugriff. An den Web-Server ergeht eine GET-Anfrage. Im Header-Feld If-Modified-Since wird das Datum übermittelt.

Der Server antwortet mit 304 Not Modified ohne die Seite, da diese dem Client ja vorliegt oder mit einer normalen 200 OK-Antwort mit der Seite, wenn die vorliegende Seite neuer ist.

Cookies

HTTP ist eigentlich statuslos. Das bedeutet, dass eine Anfrage nicht mehr weiß, was in der vorigen Anfrage geschehen ist. Für verlinkte Dokumente ist das ausreichend, aber bei einem Shop will der Benutzer seinen Einkaufswagen behalten, wenn er auf die nächste Seite wechselt.

Cookies sind kleine Dateien, die der Server beim Eröffnen der Shopping-Tour an den Client (Browser) im Header-Feld set-cookie sendet. Der Cookie enthält den (eindeutigen) Namen des Shops und eine eindeutige Sitzungsnummer. Der Client speichert das Cookie (Shopname und Sitzungsnummer) in seinem lokalen Cache. Bei einem Aufruf einer anderen Seite des Shops fragt der Server, ob ein Cookie vorliegt und ermittelt anhand der Sitzungsnummer den Warenkorb des Benutzers.

Probleme ergeben sich, wenn Cookies an Server weitergegeben werden, die gar nicht der Shop-URL entsprechen, weil dieser Server dann nachvollziehen kann, welchen Shop der Client besucht hat.