Was steckt in einer HTTP-Response?

Jedes Mal, wenn Ihr Browser eine Seite lädt oder Ihr JavaScript fetch() aufruft, sendet ein Server eine HTTP-Response zurück. Sie sehen das Ergebnis – eine gerenderte Seite, einige JSON-Daten, eine Fehlermeldung – aber die Response selbst enthält mehr Struktur, als den meisten Entwicklern bewusst ist. Das Verständnis dieser Struktur gibt Ihnen ein klareres mentales Modell beim Debugging in den DevTools oder bei der Verarbeitung von Responses im Code.

Eine HTTP-Response besteht aus drei Teilen: einer Statuszeile, Headern und einem optionalen Body.

Die Anatomie einer HTTP-Response: Status, Header, Body

Die Statuszeile

In HTTP/1.1 beginnt die Response mit einer einzigen Statuszeile:

HTTP/1.1 200 OK

Diese Zeile enthält die Protokollversion, einen dreistelligen Statuscode und eine menschenlesbare Reason-Phrase. Die Reason-Phrase dient nur zur Information – der Statuscode ist das, worauf Browser und Clients tatsächlich reagieren.

HTTP-Statuscodes sind nach ihrer ersten Ziffer gruppiert:

Ein Hinweis zu HTTP/2 und HTTP/3: Die oben gezeigte textuelle Statuszeile ist spezifisch für das HTTP/1.1-Wire-Format. In HTTP/2 und HTTP/3 gibt es keine Statuszeile. Stattdessen wird der Status über einen :status-Pseudo-Header übermittelt (z. B. :status: 200). Die Semantik ist identisch – der Statuscode bedeutet dasselbe – aber die Darstellung unterscheidet sich. Die DevTools normalisieren die Darstellung, sodass Sie den vertrauten Statuscode unabhängig von der Protokollversion sehen.

HTTP-Response-Header: Was sie tatsächlich tun

Response-Header sind Metadaten. Sie teilen dem Browser mit, wie die Response zu handhaben ist, nicht was der Inhalt ist. Jeder Header ist ein case-insensitiver Name, gefolgt von einem Doppelpunkt und einem Wert.

Hier sind die Kategorien, denen Sie am häufigsten begegnen werden:

Content-Metadaten

• Content-Type: application/json; charset=utf-8 – teilt dem Browser mit, in welchem Format der Body vorliegt und wie er zu dekodieren ist.
• Content-Length: 1024 – die Größe des Body in Bytes.

Caching

• Cache-Control: max-age=3600, public – weist den Browser und CDNs an, wie lange die Response gecacht werden soll.
• ETag: "abc123" – ein Fingerabdruck der Ressource, der für bedingte Anfragen verwendet wird. Wenn sich die Ressource nicht geändert hat, gibt der Server 304 Not Modified anstelle des vollständigen Body zurück.

Sicherheit

• Content-Security-Policy – beschränkt, aus welchen Quellen der Browser Skripte, Styles und andere Ressourcen laden kann.
• Strict-Transport-Security – teilt dem Browser mit, dass er für eine bestimmte Dauer nur über HTTPS verbinden soll.

Cookies

• Set-Cookie: session=xyz; HttpOnly; Secure – weist den Browser an, ein Cookie zu speichern. Eine einzelne Response kann mehrere Set-Cookie-Header enthalten, einen pro Cookie.

Eine wichtige Einschränkung: Nicht alle Response-Header sind für Frontend-JavaScript zugänglich. Standardmäßig macht die Fetch API nur einen kleinen Satz „sicherer” Header aus Cross-Origin-Responses verfügbar. Server müssen zusätzliche Header explizit in Access-Control-Expose-Headers auflisten, damit Ihr JavaScript sie lesen kann.

Der Response-Body

Der Body ist die eigentliche Payload – HTML, JSON, ein Bild, eine Datei. Nicht jede Response hat einen. Eine 204 No Content- oder 304 Not Modified-Response lässt den Body absichtlich weg. In diesen Fällen ist der Statuscode selbst die Nachricht.

Der Content-Type-Header teilt dem Browser mit, wie er interpretieren soll, was im Body ankommt.

Weniger bekannte Features, die Sie kennen sollten

HTTP-Responses können auch informative Responses wie 103 Early Hints enthalten, die es Servern ermöglichen, Ressourcen zum Vorladen vorzuschlagen, bevor die Haupt-Response eintrifft. Trailers – Header, die nach dem Body gesendet werden – existieren in HTTP/1.1 (mit Chunked Transfer Encoding) und in HTTP/2 und HTTP/3 als Trailing Headers, werden aber in der alltäglichen Frontend-Arbeit selten angetroffen. Diese sind wissenswert, aber Sie werden sie in den DevTools nicht oft sehen.

Fazit

Stellen Sie sich eine HTTP-Response wie einen Briefumschlag vor. Der Statuscode sagt Ihnen, ob die Zustellung erfolgreich war. Die Header sind Anweisungen auf der Außenseite – Vorsicht zerbrechlich, nach dem Öffnen kühlen, läuft in 24 Stunden ab. Der Body ist das, was drin ist. Wenn etwas nicht funktioniert, prüfen Sie zuerst den Statuscode, dann die Header – sie sagen Ihnen normalerweise genau, was schiefgelaufen ist und was als Nächstes zu tun ist.

FAQs

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.