HTTP
Das Anwendungsprotokoll des Web — definiert wie Browser und Server Anfragen und Antworten austauschen.
Aktualisiert: 23. Februar 2026
Was ist HTTP?
HTTP (HyperText Transfer Protocol) ist das Anwendungsprotokoll, auf dem das World Wide Web aufbaut. Es definiert, wie Nachrichten zwischen einem Client (Browser, App, API-Consumer) und einem Server (Webserver, API-Backend) strukturiert und übertragen werden. Jede Webseite, jede REST-API-Anfrage, jeder Bild-Download im Browser läuft über HTTP — oder seine verschlüsselte Variante HTTPS.
HTTP ist zustandslos (stateless): Jede Anfrage ist unabhängig von der vorherigen. Der Server merkt sich nichts zwischen Requests — was Skalierbarkeit ermöglicht, aber auch erklärt, warum Sessions, Cookies und Tokens existieren: Sie tragen den Zustand im Request mit.
Kurzprofil
- Typ: Anwendungsprotokoll (Layer 7 OSI-Modell)
- Port: 80 (HTTP), 443 (HTTPS)
- Aktuell: HTTP/3 (RFC 9114, 2022) — basiert auf QUIC
- Zustand: Stateless (zustandslos)
- Spezifikation: RFC 9110 (HTTP Semantics)
- Relevanz für WordPress/Web: Grundlegend
Wie funktioniert HTTP?
Ein HTTP-Austausch besteht aus Request (Anfrage) und Response (Antwort). Beide haben denselben Grundaufbau: eine Startzeile, Header-Felder und optional einen Body.
HTTP Request:
GET /wp-json/wp/v2/posts HTTP/1.1
Host: example.com
Accept: application/json
Authorization: Bearer <token>
HTTP Response:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=3600
[{"id": 1, "title": {...}, ...}]
HTTP-Methoden beschreiben die Absicht der Anfrage:
GET— Ressource abrufen (keine Nebeneffekte)POST— Ressource erstellen / Daten sendenPUT/PATCH— Ressource ersetzen / teilweise aktualisierenDELETE— Ressource löschenHEAD— Nur Header ohne Body (für Cache-Prüfungen)OPTIONS— Verfügbare Methoden abfragen (wichtig für CORS)
HTTP-Statuscodes signalisieren das Ergebnis:
2xx— Erfolg (200 OK, 201 Created, 204 No Content)3xx— Weiterleitungen (301 Moved Permanently, 302 Found)4xx— Client-Fehler (400 Bad Request, 401 Unauthorized, HTTP 403 Forbidden, 404 Not Found)5xx— Server-Fehler (500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable)
HTTP in der Praxis
HTTP-Versionen haben sich erheblich weiterentwickelt:
HTTP/1.1 (1997): Standard bis ~2015. Ein Request pro Verbindung — führte zu "Head-of-Line-Blocking" und dem Trick, Ressourcen auf mehrere Domains aufzuteilen.
HTTP/2 (2015): Multiplexing (mehrere Requests über eine Verbindung gleichzeitig), Header-Komprimierung (HPACK), Server Push. Funktioniert nur über HTTPS. Heute Standard auf modernen Servern.
HTTP/3 (2022): Ersetzt TCP durch QUIC (UDP-basiert). Kein Head-of-Line-Blocking auf Transport-Ebene, schnellerer Verbindungsaufbau (0-RTT Resumption). Cloudflare, Google und viele CDNs unterstützen HTTP/3 bereits.
Für WordPress-Admins relevant: Nginx und Traefik unterstützen HTTP/2 nativ. Aktivierung in Nginx:
listen 443 ssl http2;
Das Wichtigste
- HTTP ist das Basisprotokoll des Web: Request → Response, stateless
- Methoden definieren Absicht (GET, POST, PUT, DELETE)
- Statuscodes signalisieren Ergebnis (2xx Erfolg, 4xx Client-Fehler, 5xx Server-Fehler)
- HTTP/2 ist Standard: Multiplexing, komprimierte Header, nur über HTTPS
- HTTP/3 (QUIC) löst TCP-basierte Performance-Probleme
Was passiert wenn HTTP-Grundlagen falsch konfiguriert sind?
Falsche HTTP-Header-Konfiguration ist eine der häufigsten Ursachen für schwer diagnostizierbare Probleme: Falsches Cache-Control lässt private Daten im öffentlichen Cache landen. Fehlendes Content-Type lässt Browser MIME-Sniffing betreiben — ein Einfallstor für XSS. Fehlende Sicherheitsheader (HSTS, CORP, COEP) öffnen Angriffsszenarien.
Bei WordPress ist OPTIONS-Request-Handling besonders wichtig: WordPress blockiert häufig OPTIONS-Requests durch Security-Plugins oder Webserver-Konfiguration — was CORS-Preflight-Requests fehlschlagen lässt und API-Aufrufe aus Browsern unterbricht.
Häufige Fragen
Was ist der Unterschied zwischen HTTP und dem Web? HTTP ist das Protokoll; das Web ist das System darüber. Das Web nutzt HTTP für die Übertragung, aber HTTP kann auch für andere Zwecke eingesetzt werden — z.B. REST APIs, Webhook-Callbacks, Health-Check-Endpoints — ohne dass dabei "Webseiten" übertragen werden.
Warum ist HTTP zustandslos, obwohl Websites Logins haben? Logins werden über Cookies oder Tokens realisiert, die bei jedem Request mitgesendet werden. Der Zustand steckt im Request, nicht im Server. Das ist Absicht: Zustandslosigkeit ermöglicht Load Balancing (jeder Server kann jeden Request bearbeiten) und vereinfacht Fehlerbehandlung.
Wann sollte man PUT statt PATCH verwenden?
PUT ersetzt die gesamte Ressource (idempotent: mehrfaches Senden hat gleiche Wirkung wie einmaliges). PATCH aktualisiert nur die gesendeten Felder. Bei WordPress REST API: PUT für vollständiges Update eines Posts, PATCH für einzelne Felder wie nur den Titel.
Verwandte Begriffe
OTLP · TCP · XML-RPC