Sie öffnen einen Onlineshop, und er erscheint in Ihrer Sprache, hält Sie angemeldet und lädt schnell aus einem Cache. Nichts davon hat die Seite selbst entschieden. Bevor ihre erste Zeile ankommt, tauschen Ihr Browser und der Server ein Dutzend kurzer Zeilen darüber aus, wer fragt, was er annimmt und was zurückkommt. Diese Zeilen sind HTTP-Header.
Dieser Beitrag zeigt eine echte, mit curl aufgezeichnete Anfrage samt Antwort, die Header, denen Sie am häufigsten begegnen, ob bei den Namen Groß- und Kleinschreibung zählt und wie Sie Header in Chrome und mit curl lesen. Zum Schluss folgen Sicherheits-Header für Website-Betreiber, die Header, die ein Proxy hinzufügt oder liest, und sechs häufige Fragen.
Was sind HTTP-Header?
HTTP-Header sind benannte Zusatzinformationen, die mit einer Anfrage oder einer Antwort vor dem eigentlichen Inhalt gesendet werden. RFC 9110, der Standard, der HTTP definiert, nennt die vor dem Inhalt gesendeten Felder „header fields“, kurz Header. Jeder Header ist eine Zeile aus einem Namen, einem Doppelpunkt und einem Wert, etwa Accept-Language: de-DE.
Jede HTTP-Nachricht ist gleich aufgebaut: eine erste Zeile, die Header, eine Leerzeile und danach, falls vorhanden, der Body. In einer Anfrage nennt die erste Zeile Methode und Pfad (GET /), in einer Antwort den Statuscode (200 OK). Der Body ist die Seite, das Bild oder die Daten; die Header beschreiben ihn und die beiden Seiten des Austauschs.
Anfrage-Header gehen von Ihrem Browser oder Ihrer App zum Server, Antwort-Header kommen zurück. Die HTTP-Header-Referenz von MDN führt jeden Standard-Header nach Gruppen geordnet auf. Namen, die mit X- beginnen, sind selbst erfundene Erweiterungen; von dieser Namensgewohnheit wird seit 2012 offiziell abgeraten, doch viele solche Namen sind weiter in Gebrauch.
Wie funktionieren Anfrage und Antwort mit Headern?
Ein Seitenaufruf besteht aus einer Anfrage und einer Antwort, jede mit eigenen Headern:
- Ihr Browser verbindet sich mit dem Server. Bei einer
https://-Adresse richtet er zuerst die Verschlüsselung ein. - Er sendet die Anfragezeile und die Anfrage-Header:
GET /, dannHost,User-Agent,Accept,Accept-Languageund alle Cookies, die er für diese Website gespeichert hat. - Eine Leerzeile beendet die Header. Ein Formular oder ein API-Aufruf hängt danach einen Body an.
- Der Server liest die Header:
Hostbestimmt die Website,Accept-Languagedie Sprache,Cookieden angemeldeten Nutzer. - Er antwortet mit einer Statuszeile und Antwort-Headern, etwa
200 OKundContent-Type; danach folgen eine Leerzeile und der Body. - Der Browser richtet sich danach: Er zeigt die Seite an, speichert Cookies, legt eine Kopie im Cache ab oder folgt einer Weiterleitung.
Wie sehen eine echte HTTP-Anfrage und -Antwort aus?
Hier ist ein Austausch mit example.com, aufgezeichnet mit curl -v. curl ist ein Kommandozeilenwerkzeug, das Webadressen abruft und in Windows 10 und 11, macOS und den meisten Linux-Systemen bereits enthalten ist; -v (verbose, ausführlich) gibt beide Seiten aus. Wir haben den Befehl am 15. November 2026 unter Windows 11 ausgeführt und die Ausgabe auf die Header gekürzt:
> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/8.22.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Sun, 15 Nov 2026 15:40:29 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Server: cloudflare
< last-modified: Thu, 12 Nov 2026 21:56:22 GMT
< allow: GET, HEAD
< Accept-Ranges: bytes
< Age: 6679
< cf-cache-status: HIT
< alt-svc: h3=":443"; ma=86400Zeilen mit > am Anfang hat curl gesendet, Zeilen mit < hat der Server geantwortet; das einzelne > ist die Leerzeile, die die Anfrage-Header abschließt. curl sendet drei Anfrage-Header, ein Browser mehr als zehn.
Content-Type: text/html; charset=utf-8: Der Body ist eine Webseite als UTF-8-Text.Age: 6679: Das Content Delivery Network (CDN) vor der Website hält diese Kopie seit 6.679 Sekunden, also seit etwa 1 Stunde und 51 Minuten.cf-cache-status: HIT: kein Standard-Header, sondern ein eigener Vermerk dieses Netzes, dass die Kopie aus seinem Cache kam.alt-svc: h3=":443": Die Website spricht auf Port 443 auch HTTP/3.
Achten Sie auf Content-Type neben last-modified: eine einzige Antwort, zwei Schreibweisen für Namen.
Unterscheiden HTTP-Header Groß- und Kleinschreibung?
Nein, bei Header-Namen spielt Groß- und Kleinschreibung keine Rolle: Content-Type, content-type und CONTENT-TYPE sind derselbe Header. RFC 9110 sagt das in einer Zeile: „Field names are case-insensitive.“ Als wir dieselbe Seite über unverschlüsseltes http:// abriefen, schrieb der Server Last-Modified und Allow sogar mit großen Anfangsbuchstaben.
Für Werte gelten die Regeln des jeweiligen Headers. text/html und TEXT/HTML bezeichnen denselben Dateityp, aber ein Cookie-Wert oder ein Login-Token muss genau so zurückgehen, wie der Server ihn gesendet hat.
HTTP/2 und HTTP/3, die neueren Versionen des Protokolls, schreiben kleingeschriebene Namen vor; deshalb zeigen die Chrome-Entwicklertools content-type. In unserem Test lud Chromium example.com über HTTP/3, und seine Anfrage begann mit :method, :path, :scheme und :authority. Diese Pseudo-Header tragen, was bei HTTP/1.1 in der ersten Zeile und im Host-Header steht.
Vergleichen Sie Header-Namen in Ihrem Code ohne Rücksicht auf Groß- und Kleinschreibung. Das Headers-Objekt von JavaScript und die Python-Bibliothek requests tun das bereits; ein einfaches Dictionary tut es nicht.
Welche Anfrage-Header sind am häufigsten?
Anfrage-Header beschreiben, wer fragt und was er annimmt:
| Header | Was er dem Server sagt | Beispielwert |
|---|---|---|
Host | Welche Website Sie aufrufen | example.com |
User-Agent | Browser oder App samt Version | curl/8.22.0 |
Accept | Dateitypen, die Sie verarbeiten können | text/html |
Accept-Language | Sprachen, die Sie bevorzugen | de-DE,de;q=0.9 |
Cookie | Für diese Website gespeicherte Cookies | theme=dark |
Authorization | Anmeldung bei der Website oder API | Bearer <token> |
Referer | Seite, von der Sie kommen | https://example.com/ |
Dank Host kann ein Server mit einer einzigen IP-Adresse viele Websites ausliefern: Er liest den Namen und wählt die passende Website. Über Accept-Language wählt eine Website eine Sprache, bevor Sie selbst eine auswählen; die q-Zahlen sind Gewichte von 0 bis 1, de-DE,de;q=0.9 bedeutet also zuerst Deutsch für Deutschland, danach jede Form von Deutsch.
Cookie bringt die kleinen Werte zurück, die eine Website früher mit Set-Cookie gespeichert hat, etwa die Sitzungs-ID einer Anmeldung. Was sind Cookies? Wofür Websites sie verwenden geht diesen Austausch Schritt für Schritt durch.
Authorization trägt Anmeldedaten für die Website selbst, oft nach einer Antwort 401 Unauthorized; der Standard verbietet einem Proxy, diesen Header zu verändern. Referer, im Standard falsch geschrieben, nennt die Seite, deren Link Sie hierher geführt hat; bei einem Link auf eine andere Website senden Browser standardmäßig nur den Ursprung (Origin), etwa https://example.com/. Chrome sendet außerdem eigene Header wie sec-ch-ua, eine kurze Liste von Browsermarken und -versionen.
Welche Antwort-Header sind am häufigsten?
Antwort-Header sagen dem Browser, was er bekommen hat und was er damit tun soll:
| Header | Was er dem Browser sagt | Beispielwert |
|---|---|---|
Content-Type | Art der Datei im Body | application/json |
Cache-Control | Ob und wie lange zwischengespeichert wird | max-age=3600 |
Set-Cookie | Ein Cookie, das gespeichert werden soll | theme=dark; Secure |
Location | Adresse, die als Nächstes aufgerufen wird | /login |
Retry-After | Wie lange gewartet werden soll | 120 |
Strict-Transport-Security | Ab jetzt ausschließlich HTTPS verwenden | max-age=31536000 |
Content-Type entscheidet, was der Browser mit dem Body macht: text/html als Seite darstellen, image/png als Bild zeigen, application/json an ein Skript übergeben. Ein falscher Wert ist der Grund, warum eine Seite manchmal rohen Code zeigt. Content-Disposition: attachment bittet den Browser dagegen, die Datei herunterzuladen.
Cache-Control legt die Cache-Regeln fest: max-age=3600 erlaubt die Wiederverwendung eine Stunde lang, no-store verbietet, überhaupt eine Kopie zu behalten. Set-Cookie kann in einer Antwort mehrfach vorkommen, eine Zeile pro Cookie. Location kommt mit Weiterleitungen (den 3xx-Codes) und nennt die neue Adresse.
Retry-After kommt mit 503 Service Unavailable und 429 Too Many Requests und gibt an, wie lange gewartet werden soll, in Sekunden oder als Datum. Retry-After: 120 bedeutet zwei Minuten; ein ordentlich programmierter Client wartet so lange.
Wie sehen Sie HTTP-Header in Chrome?
Chrome zeigt jeden Header jeder Anfrage in seinen Entwicklertools (DevTools), im Bereich Netzwerk. Mit den Bezeichnungen der deutschen Oberfläche:
- Öffnen Sie die Seite und drücken Sie F12 oder unter Windows Strg + Umschalt + I (auf dem Mac Cmd + Option + I). Sie können auch mit der rechten Maustaste auf die Seite klicken und Untersuchen wählen.
- Klicken Sie auf den Tab Netzwerk. Die Entwicklertools zeichnen nur auf, solange sie geöffnet sind; laden Sie die Seite deshalb neu.
- Klicken Sie in der Spalte Name auf die erste Zeile, die Seite selbst.
- Öffnen Sie den Tab Header. Allgemein zeigt Adresse, Methode und Statuscode; darunter folgen Antwortheader und Anfrageheader.
- Setzen Sie neben einem Abschnitt ein Häkchen bei Rohdaten, um die Zeilen so zu sehen, wie sie ankamen, in ihrer ursprünglichen Reihenfolge.
Sehen Sie den Hinweis „Vorläufige Header werden angezeigt“, kam die Datei wahrscheinlich aus dem Cache des Browsers; setzen Sie oben im Bereich ein Häkchen bei Cache deaktivieren und laden Sie die Seite neu. Chromes Referenz zum Netzwerk-Bereich erklärt die übrigen Optionen, zum Beispiel wie Sie einen Header als eigene Spalte anzeigen.
Um eine Anfrage außerhalb des Browsers zu wiederholen, klicken Sie sie mit der rechten Maustaste an und wählen unter Windows Kopieren > Als cURL (cmd) kopieren, auf dem Mac Als cURL kopieren. Der Befehl enthält Ihre Cookies und einen eventuellen Login-Header; fügen Sie ihn deshalb nie in ein öffentliches Forum oder einen Chat ein.
Wie sehen Sie HTTP-Header mit curl?
curl zeigt Header in der Kommandozeile an; das ist praktisch, um Ihre eigene Website zu prüfen. Geben Sie die Befehle in der Eingabeaufforderung ein; in Windows PowerShell tippen Sie curl.exe, weil curl dort einen anderen Befehl bezeichnet.
curl -I https://example.com-I fordert mit einer HEAD-Anfrage nur die Antwort-Header an; unser Durchlauf gab dieselben Antwort-Header aus wie oben. Zwei weitere Optionen:
curl -v https://example.comzeigt die Anfrage-Header, die Antwort-Header und Details zur Verbindung.curl -I -H "Accept-Language: de" https://example.comfügt einen eigenen Header hinzu, etwa um zu testen, wie Ihre Website einem deutschsprachigen Browser antwortet.
Das in Windows enthaltene curl spricht HTTP/1.1 (die ausführliche Ausgabe meldet ALPN: curl offers http/1.1), daher sehen Sie die Namen in der Schreibweise, die der Server gewählt hat. Ein curl-Build mit HTTP/2-Unterstützung gibt sie bei Websites, die HTTP/2 sprechen, kleingeschrieben aus.
Welche Sicherheits-Header sollte eine Website senden?
Sicherheits-Header sind Antwort-Header, die für Ihre Website zusätzliche Schutzfunktionen im Browser einschalten. Sie setzen sie im Webserver, im Content Delivery Network oder in der Anwendung:
- Strict-Transport-Security (HSTS): für diese Website
max-ageSekunden lang nur HTTPS verwenden. Über unverschlüsseltes HTTP ignorieren Browser diesen Header. Ergänzen SieincludeSubDomainserst, wenn jede Subdomain über HTTPS funktioniert. - Content-Security-Policy (CSP): legt fest, woher die Seite Skripte, Stylesheets und Bilder laden darf, und begrenzt so, was ein eingeschleustes Skript anrichten kann.
- X-Content-Type-Options: nosniff: Der Browser vertraut
Content-Type, statt den Dateityp zu erraten. - X-Frame-Options oder
frame-ancestorsin der CSP: ob andere Websites Ihre Seite in einem Frame zeigen dürfen; das schützt vor Clickjacking, bei dem Besucher dazu gebracht werden, auf eine versteckte Seite zu klicken. - Referrer-Policy: wie viel von Ihrer Seitenadresse in
Refererlandet, wenn Besucher Ihre Website verlassen.
Prüfen Sie Ihre Website mit curl -I oder unter Antwortheader in den Entwicklertools. Bei Login-Cookies zählen die Flags Secure, HttpOnly und SameSite in Set-Cookie genauso viel.
Welche Header fügt ein Proxy hinzu, und welche liest er?
Ein Proxy arbeitet mit einigen eigenen Headern: Manche liest er aus Ihrer Anfrage, manche fügt er womöglich hinzu, bevor er sie weitergibt.
Proxy-Authorizationbringt Ihre Proxy-Anmeldung, etwauser:pass, zum Proxy, der sie selbst auswertet, statt sie an die Website weiterzugeben.Proxy-Authenticatekommt mit der Antwort407 Proxy Authentication Requireddes Proxys, wenn die Anmeldung fehlt oder falsch ist.Viahält fest, dass ein Vermittler die Nachricht bearbeitet hat; laut HTTP-Standard muss ein Proxy diesen Header hinzufügen.X-Forwarded-Forund seine standardisierte FormForwardedtragen die ursprüngliche IP-Adresse des Clients. RFC 7239, derForwardeddefiniert, sagt, dass ein Proxy, der Anonymität bieten soll, diesen Header nicht verwendet.
Ob ein Proxy Via oder X-Forwarded-For hinzufügt, ordnet ihn als transparenten, anonymen oder Elite-Proxy ein; Transparenter, anonymer und Elite-Proxy: die Unterschiede zeigt dieselbe Anfrage auf allen drei Stufen.
Bei HTTPS fällt das meiste davon weg. Für eine https://-Adresse bittet Ihre App den Proxy mit CONNECT, einen Tunnel zu öffnen, und ab dann reicht der Proxy verschlüsselte Bytes weiter, ohne sie zu lesen. Wir haben curl über einen kleinen Testproxy auf unserem eigenen Computer laufen lassen, mit der Platzhalter-Anmeldung user:pass:
> CONNECT example.com:443 HTTP/1.1
> Host: example.com:443
> Proxy-Authorization: Basic dXNlcjpwYXNz
> User-Agent: curl/8.22.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection established
<
> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/8.22.0
> Accept: */*Das Protokoll des Proxys verzeichnete nur den ersten Block. Die GET-Anfrage und ihre Header liefen durch den verschlüsselten Tunnel, sodass der Proxy sie weder lesen noch um Zeilen ergänzen konnte. dXNlcjpwYXNz ist einfach user:pass in Base64, also eine Kodierung und keine Verschlüsselung.
So transportiert ein HTTPS-Proxy Ihren Datenverkehr: Das Gateway von Proxynet leitet den Tunnel weiter, ohne ihn zu entschlüsseln, deshalb installieren Sie kein Zertifikat von uns. Ein Proxy ändert die IP-Adresse, die die Website sieht; er ist kein Grund, Ihre eigenen Header umzuschreiben. Ändern Sie User-Agent, Referer oder X-Forwarded-For nicht, um sich als anderer Browser oder anderer Besucher auszugeben; Skripte, die Sie betreiben, sollten einen ehrlichen User-Agent senden, der Ihr Werkzeug nennt.
Wo Ihnen HTTP-Header begegnen
- Sprachversionen: Eine Website liest
Accept-Language, um die erste Seite zu wählen, die Sie sehen. - Anmeldung: Der
Cookie-Header trägt Ihre Sitzung bei jeder Anfrage mit. - APIs: ein Token in
Authorization,Content-Type: application/jsonfür den Body. - Caching:
Cache-ControlundAgeentscheiden, ob eine gespeicherte Kopie noch aktuell ist. - Downloads:
Content-Dispositionentscheidet, ob eine Datei geöffnet oder gespeichert wird.
Häufige Fehler
- Header-Namen im Code mit Beachtung der Groß- und Kleinschreibung lesen.
headers["Content-Type"]findet in einem einfachen Dictionary keincontent-typevon einem HTTP/2-Server. - Einen „Als cURL kopieren“-Befehl weitergeben. Er enthält Ihre Cookies; wer ihn hat, kann in Ihrem Namen handeln.
X-Forwarded-Foraus dem Internet vertrauen. Ein Client kann jeden beliebigen Wert senden; verlässlich sind nur Einträge, die Ihr eigener Proxy oder Load Balancer (der Server, der den Verkehr auf Ihre Server verteilt) hinzugefügt hat.- HSTS zu früh mit
includeSubDomainseinschalten. Eine Subdomain ohne HTTPS wird für Besucher, die den Header gesehen haben, unerreichbar. - Cookies sich ansammeln lassen. Große Cookies schieben die Anfrage über das Header-Limit des Servers, und die Website antwortet mit 400 oder 431.
Entscheidungshilfe
| Ihr Ziel | Wo Sie nachsehen oder was Sie nutzen |
|---|---|
| Sehen, was Ihr Browser sendet | Entwicklertools > Netzwerk > Header |
| Die Antwort einer Website schnell prüfen | curl -I |
| Herausfinden, wohin eine Weiterleitung führt | Location in der Antwort |
| Verstehen, warum eine Seite in einer anderen Sprache erscheint | Accept-Language in der Anfrage |
| Die eigene Website absichern | HSTS, CSP, nosniff, Referrer-Policy |
| Sich bei einem Proxy anmelden | Proxy-Authorization, von Ihrer App gesetzt |
Häufige Fragen
Was ist der User-Agent-Header?
Das ist der Anfrage-Header, der den Browser oder das Programm nennt, das die Anfrage stellt, mit Version und meist auch dem Betriebssystem; curl sendet curl/8.22.0. Websites nutzen ihn für Statistiken und um Eigenheiten einzelner Browser auszugleichen. Was ist ein User-Agent? Auslesen und ändern zeigt, wie Sie Ihren eigenen auslesen.
Was bedeutet X-Forwarded-For?
Das ist ein Header, in den ein Proxy oder Load Balancer die IP-Adresse des Clients schreibt, der ihm die Anfrage geschickt hat, damit der Server dahinter die Adresse des Besuchers sieht. Er wurde nie formal standardisiert; Forwarded (RFC 7239) ist die standardisierte Fassung. Jeder kann ihn senden, deshalb sollte ein Server nur den Einträgen trauen, die sein eigener Proxy hinzugefügt hat.
Werden HTTP-Header bei HTTPS verschlüsselt?
Ja. Bei HTTPS reisen die Header zusammen mit dem Body innerhalb der Verschlüsselung, sodass Netze und Proxys unterwegs sie nicht lesen können. Sichtbar bleibt die IP-Adresse des Servers und in den meisten Fällen auch der Domainname, der beim Aufbau der Verbindung gesendet wird.
Was sind HTTP-Header in einer API?
Dieselben Header, nur bewusster eingesetzt. Ein API-Aufruf sendet meist einen Schlüssel oder ein Token in Authorization (manche APIs nutzen einen eigenen Header wie X-API-Key), kennzeichnet den Body mit Content-Type: application/json und fordert mit Accept JSON an. Auf zu viele Anfragen folgt oft eine 429 mit Retry-After.
Was bedeutet „HTTP header is larger than 8192 bytes“?
Die Meldung bedeutet, dass eine Anfrage oder Antwort mehr Header-Daten enthielt, als die verarbeitende Software annimmt. Der Wortlaut stammt von Netty, einer Java-Bibliothek für Netzwerkprogrammierung mit einem Standardlimit von 8.192 Byte; andere Zahlen wie 10.240 sind eigens konfigurierte Limits. HTTP selbst legt kein Maximum fest. Als Besucher löschen Sie die Cookies dieser Website; als Entwickler verkleinern Sie Cookies oder Tokens oder heben das Limit an.
Warum ist der Referer-Header falsch geschrieben?
Weil der falsch geschriebene Name schon in der HTTP/1.0-Spezifikation von 1996 stand und Software überall den Header unter diesem Namen liest. Der heutige Standard behält Referer mit dem Vermerk „[sic]“ bei; der neuere Header Referrer-Policy ist richtig geschrieben.
Fazit
HTTP-Header sind die Name: Wert-Zeilen am Anfang jeder Anfrage und Antwort. Anfrage-Header nennen Website, Browser, Sprachen, Cookies und Anmeldedaten; Antwort-Header sagen, was der Body ist, wie lange er zwischengespeichert wird, welche Cookies gespeichert werden und wohin es als Nächstes geht. Bei den Namen spielt Groß- und Kleinschreibung keine Rolle, und HTTP/2 und HTTP/3 schreiben sie klein. Lesen Sie Header in den Entwicklertools oder mit curl, und senden Sie von Ihrer eigenen Website Sicherheits-Header. Bei HTTPS sieht ein Proxy nur die kurze CONNECT-Anfrage mit dem Namen der Website und Ihrer Proxy-Anmeldung; wenn Sie Ihren eigenen Datenverkehr über einen Proxy leiten möchten, beginnen Sie mit unseren Proxy-Diensten.




