Was ist HTTP?
HTTP, das HyperText Transfer Protocol, ist die Art und Weise, wie Clients und Server im Web kommunizieren. Ein Client sendet einen Request, in dem beschrieben wird, was er benötigt; ein Server sendet eine Response, die das Ergebnis beschreibt. Jeder Seitenaufruf, jeder API-Call, jedes Bild und jede Schriftart wird auf diese Weise übertragen.
Es handelt sich um ein einfaches, textbasiertes und stateless (zustandsloses) Protokoll: Jeder Request steht für sich allein, und der Server erinnert sich nicht an vorherige Anfragen, es sei denn, ein Cookie oder ein ähnlicher Mechanismus überträgt diesen Zustand. Diese Einfachheit ist der Grund, warum HTTP auf das gesamte Web skalieren konnte.
Requests
Ein Request besteht aus einer Methode, einem Pfad, Headern und optional einem Body.
POST /api/users HTTP/2
Host: example.com
Content-Type: application/json
Accept: application/json
Authorization: Bearer <token>
{ "name": "Ada" }
Die Methode gibt an, um welche Art von Aktion es sich handelt. Der Pfad identifiziert die Ressource. Header übertragen Metadaten und der Body enthält die Daten für Methoden wie POST und PUT.
| Methode | Zweck | Safe | Idempotent |
|---|---|---|---|
| GET | Ressource lesen | Ja | Ja |
| POST | Erstellen oder Auslösen | Nein | Nein |
| PUT | Ressource ersetzen | Nein | Ja |
| PATCH | Teilweise aktualisieren | Nein | Nein |
| DELETE | Ressource entfernen | Nein | Ja |
Safe bedeutet, dass der Zustand nicht verändert wird; idempotent bedeutet, dass eine mehrfache Ausführung denselben Effekt hat wie eine einmalige Ausführung. Diese Eigenschaften sind entscheidend für Caching, Retries und Proxies.
Antworten und Statuscodes
Eine Antwort besteht aus einem Statuscode, Headern und einem Body.
HTTP/2 201 Created
Content-Type: application/json
Location: /api/users/42
{ "id": 42, "name": "Ada" }
Der Statuscode teilt dem Client mit, was passiert ist. Hier sind die gängigsten Codes:
- 200 OK — Erfolg.
- 201 Created — eine neue Ressource wurde erstellt.
- 204 No Content — Erfolg, jedoch ohne Body.
- 301 / 302 — permanente und temporäre Weiterleitungen.
- 304 Not Modified — die gecachte Kopie ist noch gültig.
- 400 Bad Request — ungültige Eingabe.
- 401 Unauthorized — nicht authentifiziert.
- 403 Forbidden — authentifiziert, aber nicht berechtigt.
- 404 Not Found — Ressource nicht gefunden.
- 500 Internal Server Error — Serverfehler.
Die Rückgabe des richtigen Codes ist keine Pedanterie: Clients, Caches und Monitoring-Systeme sind alle darauf angewiesen.
Header
Header bilden die Metadaten-Ebene. Zu den gängigen Request-Headern gehören Accept, Content-Type, Authorization, Cookie und User-Agent. Zu den gängigen Response-Headern gehören Content-Type, Content-Length, Cache-Control, Set-Cookie sowie Security-Header wie Content-Security-Policy.
// fetch.js
const res = await fetch("/api/posts", {
headers: {
Accept: "application/json",
Authorization: `Bearer ${token}`,
},
});
Über Header werden Content Negotiation, Authentifizierung, Caching und Security-Policies definiert.
Cookies und Sessions
HTTP ist zustandslos, weshalb Server Cookies verwenden, um wiederkehrende Nutzer zu erkennen. Der Server sendet Set-Cookie, und der Browser sendet dieses Cookie bei nachfolgenden Anfragen an denselben Origin zurück.
Session-Cookies sollten immer wie folgt konfiguriert sein:
Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax; Path=/
- HttpOnly verhindert, dass JavaScript darauf zugreifen kann, was die Wirkung von XSS abschwächt.
- Secure stellt sicher, dass das Cookie nur über HTTPS gesendet wird.
- SameSite schränkt das Senden über verschiedene Seiten hinweg ein, was zur Prävention von CSRF beiträgt.
Der Web Security Guide bietet einen vollständigen Überblick.
Caching
Caching ist das wertvollste HTTP-Feature für die Performance. Dabei arbeiten zwei Mechanismen zusammen:
- Freshness (Aktualität) mittels
Cache-Control, wodurch festgelegt wird, wie lange eine Antwort wiederverwendet werden darf. - Validation (Validierung) mittels
ETagoderLast-Modified, wodurch der Client fragen kann: „Hat sich das geändert?“ und im Falle einer negativen Antwort einen304 Not Modifiederhält.
# versioned assets: cache for a year
Cache-Control: public, max-age=31536000, immutable
# HTML: revalidate every time
Cache-Control: no-cache
Versehen Sie Ihre Assets mit einem Content-Hash (Fingerprinting) und cachen Sie diese aggressiv; eine geänderte Datei erhält einen neuen Namen. Servieren Sie HTML mit einer kurzen Cache-Dauer und einer Revalidierung, damit Deployments sofort übernommen werden.
HTTPS und TLS
HTTPS ist HTTP über TLS. TLS erfüllt drei Aufgaben:
- Verschlüsselung des Traffics, sodass dieser während der Übertragung nicht mitgelesen werden kann.
- Authentifizierung des Servers mittels eines Zertifikats.
- Sicherstellung der Integrität, damit Daten nicht unbemerkt verändert werden können.
Besorgen Sie sich ein Zertifikat (es gibt kostenlose Optionen), leiten Sie den gesamten HTTP-Traffic auf HTTPS um und aktivieren Sie HSTS, um zu verhindern, dass Browser für Ihre Domain überhaupt noch unverschlüsseltes HTTP verwenden. Behandeln Sie HTTP als Legacy-Protokoll.
HTTP-Versionen
- HTTP/1.1 — eine Anfrage pro Verbindung zurzeit, weshalb Websites früher Dateien oft zusammengefasst (concatenated) haben.
- HTTP/2 — multiplexed viele Anfragen über eine einzige Verbindung und komprimiert Header, wodurch die meisten dieser Workarounds überflüssig wurden.
- HTTP/3 — läuft über QUIC, einem UDP-basierten Transportprotokoll, was die Verbindungs-Latenz reduziert und Paketverluste besser handhabt.
Die Bereitstellung von HTTPS aktiviert in der Regel automatisch HTTP/2 oder HTTP/3 über Ihren Server oder Ihr CDN. In den seltenen Fällen, in denen dies nicht geschieht, müssen Sie kaum Anpassungen an Ihrem Code vornehmen.
Best Practices
- Überall HTTPS verwenden und HTTP mittels HSTS auf HTTPS umleiten.
- Präzise Status-Codes und aussagekräftige Error-Bodies zurückgeben.
- Methoden sicher und idempotent halten, wie es deren Definitionen erfordern.
Cache-Controlund Validatoren bewusst setzen.- HttpOnly, Secure und SameSite Cookies für Sessions verwenden.
- Security-Header wie CSP und
X-Content-Type-Optionssetzen. - HTTP/2 oder HTTP/3 bevorzugen und die Aushandlung der Plattform überlassen.
Häufige Fehler
- Rückgabe von 200 bei Fehlern, was Clients und Caches beeinträchtigt.
- Mutation von Daten via GET, was unsicher ist und zu Caching oder Prefetching führen kann.
- Deaktivierung des Cachings für alle Anfragen, was die Performance verschlechtert.
- Speichern von Session-Tokens in
localStorageanstatt in einem Cookie. - Fehlende Weiterleitung von HTTP auf HTTPS.
- Ignorieren von
Content-Type, was zu Parse-Fehlern führt.
Wie geht es weiter?
HTTP ist die gemeinsame Sprache des Webs, und es lohnt sich, diese fließend zu beherrschen. Vertiefe dein Wissen mit den Internet-Grundlagen, verstehe DNS, sende Anfragen aus JavaScript mit Fetch und sichere deinen Datenverkehr mit dem Web Security Guide.