EMZETT.HTTP
Kurz: Hypertext Transfer Protocol — das Protokoll, über das Browser und Server Webseiten und andere Ressourcen austauschen, unverschlüsselt.
Genauer: Funktioniert nach dem Request-Response-Prinzip: Der Client schickt eine Request (z. B. GET /seite), der Server antwortet mit Statuscode und Inhalt. Baut auf TCP auf. Da alles im Klartext übertragen wird (auch Passwörter, Cookies), heute größtenteils durch HTTPS ersetzt.
Im Detail
Aufbau von Request und Response
Ein typischer HTTP-Request und die dazugehörige Antwort sehen (vereinfacht) so aus:
GET /index.html HTTP/1.1
Host: emzett-digital.com
User-Agent: Mozilla/5.0
--- Antwort ---
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234
<html>...</html>
Sowohl Request als auch Response bestehen aus einer Startzeile, mehreren Header-Feldern (Metadaten wie Content-Type oder Cache-Anweisungen) und optional einem Body mit den eigentlichen Nutzdaten. Der Host-Header ist dabei essenziell: Da auf einem einzigen Server mit derselben IP-Adresse oft mehrere Websites gehostet werden (Virtual Hosting), verrät erst dieser Header, welche der Websites gemeint ist.
HTTP-Methoden
HTTP arbeitet nach einer Handvoll standardisierter Methoden, die jeweils eine bestimmte Absicht ausdrücken: GET (Ressource abrufen, ohne Seiteneffekte — sollte beliebig oft wiederholbar sein, ohne etwas zu verändern), POST (neue Daten anlegen/senden, typischerweise mit Seiteneffekten), PUT/PATCH (bestehende Daten vollständig ersetzen bzw. teilweise ändern), DELETE (Ressource löschen). Diese Unterscheidung ist mehr als nur Konvention — Browser und Zwischenstationen (Proxies, Caches) verlassen sich darauf, dass ein GET niemals Daten verändert, und cachen entsprechende Antworten aggressiv, was bei einem fälschlicherweise mit GET implementierten löschenden Endpunkt zu ungewollten Wiederholungen führen kann.
Statuscodes
Die Antwort trägt immer einen dreistelligen Statuscode, dessen erste Ziffer die Kategorie verrät: 1xx (informativ, selten sichtbar), 2xx (Erfolg, z. B. 200 “OK” oder 201 “Created”), 3xx (Weiterleitung, z. B. 301 für eine dauerhafte Umleitung), 4xx (Client-Fehler, z. B. 404 “Not Found” oder 401 “Unauthorized”), 5xx (Server-Fehler, z. B. 500 “Internal Server Error” bei einem unerwarteten Absturz der Anwendung). Diese grobe Einteilung erlaubt es Clients, sinnvoll auf unbekannte, aber neue Statuscodes zu reagieren — ein Client, der einen ihm unbekannten 4xx-Code sieht, weiß zumindest, dass es sich um einen eigenen Fehler handelt, nicht um einen Server-Fehler.
Zustandslosigkeit und ihre Folgen
Wichtig ist, dass HTTP von Haus aus zustandslos (stateless) ist: Jeder Request ist für den Server unabhängig von allen vorherigen — der Server “erinnert” sich nicht von selbst, dass derselbe Client gerade eingeloggt ist oder vorher schon etwas in den Warenkorb gelegt hat. Zustandsbehaftete Funktionen wie eingeloggt bleiben laufen deshalb über zusätzliche Mechanismen wie Cookies oder Session-Tokens, die bei jedem Request erneut vom Client mitgeschickt werden müssen, damit der Server den Kontext wiederherstellen kann.
Entwicklung über die Versionen
Seit HTTP/2 (2015) laufen außerdem mehrere Requests parallel über eine einzige TCP-Verbindung (Multiplexing), statt wie bei HTTP/1.1 für jeden Request eine neue Verbindung aufzubauen oder auf begrenzte parallele Verbindungen pro Domain angewiesen zu sein — das hat die Ladezeiten moderner Webseiten mit vielen Ressourcen (Bilder, Skripte, Stylesheets) deutlich verbessert. HTTP/3 geht noch einen Schritt weiter und ersetzt TCP komplett durch QUIC (basierend auf UDP), um das sogenannte “Head-of-Line Blocking” zu vermeiden, bei dem ein einzelnes verlorenes Paket bei TCP alle nachfolgenden Requests blockiert, selbst wenn deren Daten längst angekommen wären.