Welche HTTP-Header gibt es wofür – und wie wirken sie zusammen (Syntax, RFC, Caching, Security)?

HTTP-Header als Protokollelement: Syntax, Semantik, ABNF-Grundlagen und RFC-Einordnung

HTTP-Header sind strukturierte Metadaten im Nachrichtenformat von HTTP. Sie transportieren Steuerinformationen und Eigenschaften zu Darstellung, Aushandlung, Authentisierung, Caching, Weiterleitung und Verbindungsmanagement. In HTTP/1.1 erscheinen Header als Zeilen im Nachrichtenkopf; in HTTP/2 und HTTP/3 werden sie als benannte Felder in binär gerahmten Header-Blöcken übertragen. Unabhängig von der Transportkodierung bleibt das semantische Modell gleich: Eine HTTP-Nachricht enthält eine Menge von Header-Feldern, deren Interpretation durch Standards (RFCs) und durch registrierte Feldnamen festgelegt ist.

COMFEE Mobile Klimaanlage 3-in-1, Kapazität 9000 BTU/h, Kühlung, Belüftung,Entfeuchtung [Energieklasse A] ^ℹ︎

Rezensionen lesen^ℹ︎

Kein Angebot verfügbar.

ℹ︎ Affiliate-Link: Wenn Sie über diesen Link einkaufen, erhält der Betreiber dieser Website möglicherweise eine Provision. Für Sie bleibt der Preis dadurch gleich. Zuletzt aktualisiert am 26. Juni 2026 um 4:40. Die hier gezeigten Preise können sich zwischenzeitlich auf der Seite des Verkäufers geändert haben. Alle Angaben ohne Gewähr.
(**) UVP: Unverbindliche Preisempfehlung

Preise inkl. MwSt., zzgl. Versandkosten

Feldzeile, Feldname und Feldwert: syntaktisches Grundmodell

Das normative Basisformat für Header-Felder wird durch die HTTP Semantics (RFC 9110) und das HTTP/1.1 Messaging (RFC 9112) beschrieben. Ein Header-Feld besteht aus einem Feldnamen, gefolgt von einem Doppelpunkt, optionalem Whitespace und dem Feldwert. Feldnamen sind ASCII und case-insensitive; praktisch werden sie in der Schreibweise bewahrt, dürfen aber nicht als case-sensitive verglichen werden. Ein Header kann in einer Nachricht mehrfach vorkommen, sofern seine Semantik dies erlaubt; andernfalls gilt ein Mehrfachauftreten als ungültig oder muss zusammengeführt werden, abhängig von der jeweiligen Felddefinition.

Für HTTP/2 (RFC 9113) und HTTP/3 (RFC 9114) entfällt die Zeilenrepräsentation; Header-Felder werden über HPACK (RFC 7541) bzw. QPACK (RFC 9204) komprimiert und in Frames transportiert. Daraus folgt eine zentrale Konsequenz: Sicherheits- und Robustheitsanforderungen beziehen sich nicht nur auf das Parsing von Textzeilen, sondern auch auf die Normalisierung von Feldnamen, die Behandlung wiederholter Felder und auf Größenlimits (Header-Liste, einzelne Werte), die in Implementierungen und in Proxys/CDNs oft gesondert durchgesetzt werden.

ABNF-Grundlagen: Tokens, Listen und Parameter

Die formale Grammatik wird in den RFCs als ABNF (Augmented Backus–Naur Form) angegeben. In der Praxis dominieren wenige Muster: Token-basierte Werte (z. B. Direktiven), Listen von Elementen (durch Kommas getrennt), sowie Parameterlisten (häufig durch Semikolon getrennt). ABNF ist dabei nicht nur Dokumentation, sondern die Grundlage für Interoperabilität: Schon kleine Abweichungen bei Whitespace, bei Quotierung oder bei der Interpretation von Kommas können dazu führen, dass Proxys unterschiedliche Werte sehen oder dass Signaturen (z. B. bei authentifizierten Requests) nicht mehr verifizieren.

Komma-separierte Listen sind in HTTP besonders verbreitet, doch nicht jeder Header ist eine Liste. Mehrfach vorkommende Felder dürfen nur dann zu einer Liste zusammengeführt werden, wenn der jeweilige Header dies explizit erlaubt. Implementierungen sollten daher nicht pauschal „joinen“, sondern header-spezifisch verarbeiten. Zudem sind strukturierte Header-Felder nach RFC 8941 ein eigener, moderner Mechanismus (z. B. Sec-CH-UA-Familie in Teilen), der ABNF-Äquivalente bewusst durch strengere Parsingregeln ersetzt; diese Felder sind im jeweiligen Registry- bzw. Header-Definitionstext als „Structured Field“ erkennbar.

• Token und Case-Insensitivität: Feldnamen und viele Token-Werte (z. B. Direktiven in Cache-Control) werden nach Spezifikation case-insensitiv verglichen; eine kanonische Ausgabeform ist Konvention, aber keine semantische Vorgabe.
• Whitespace-Regeln: Optionaler Whitespace (OWS) ist an definierten Stellen zulässig; Parser sollten tolerieren, Serializer sollten minimieren. In HTTP/1.1 sind Zeilenumbrüche innerhalb von Headern („folding“/obs-fold) in neuen Nachrichten nicht mehr erlaubt.
• Komma-Listen vs. Mehrfachfelder: Nur „list-based fields“ dürfen aus mehreren Feldzeilen zu einem Wert zusammengeführt werden; Gegenbeispiele existieren, bei denen Kommas innerhalb eines einzelnen Werts eine andere Bedeutung haben.
• Quoted-String und Escaping: Einige Header nutzen quoted-string-Syntax; korrektes Escaping verhindert Parsingfehler, besonders in Parametern wie Content-Disposition oder in Challenge-Parametern von WWW-Authenticate.
• Structured Fields (RFC 8941): Wo eingesetzt, gelten deterministische Parsing-/Serialisierungsregeln (Dictionary, List, Item). Das reduziert Ambiguität, ist aber nicht rückwirkend auf klassische Header anwendbar.

Semantik und Klassifikation: Representation, Routing, Conditionals, Controls

Semantisch lassen sich Header-Felder nach ihrer Rolle im HTTP-Modell gruppieren. „Representation Metadata“ (z. B. Content-Type, Content-Language) beschreibt die Repräsentation eines Resources. „Request Modifiers“ (z. B. Accept, Accept-Encoding) steuern die Aushandlung. „Conditional“ Header (z. B. If-None-Match, If-Modified-Since) koppeln Requests an Validatoren und Zeitstempel. „Controls“ (z. B. Cache-Control) beeinflussen Caches und Zwischenstationen. Daneben existieren „Authentication“ und „Security Context“-Header (z. B. Authorization, Origin), die strikt nach dem Bedrohungsmodell (Credential Leakage, Request Smuggling, Cache Poisoning) interpretiert werden müssen.

Für Proxys und CDNs ist entscheidend, ob ein Header „end-to-end“ oder „hop-by-hop“ wirkt. Hop-by-hop-Header gelten nur für eine einzelne Transportverbindung und dürfen nicht weitergeleitet werden. In HTTP/1.1 wurde dies über Connection und die dort aufgelisteten Feldnamen ausgedrückt; in HTTP/2 und HTTP/3 ist Connection als Feldname verboten, und hop-by-hop-Semantik wird durch die Protokollebene (z. B. Stream-/Frame-Mechanismen) bzw. durch explizite Vorgaben pro Header ersetzt. Typische hop-by-hop-Beispiele sind Transfer-Encoding (in HTTP/2/3 nicht zulässig) oder Verbindungsparameter; TE ist in HTTP/2/3 nur in der Form TE: trailers zulässig.

RFC-Einordnung und Registries: „Spec first“ statt De-facto

Die maßgeblichen Kern-RFCs sind seit der HTTP-bis-Reihe konsolidiert: RFC 9110 (Semantics), RFC 9111 (Caching), RFC 9112 (HTTP/1.1), RFC 9113 (HTTP/2), RFC 9114 (HTTP/3). Viele Header-Definitionen leben in spezialisierten RFCs, etwa für Authentisierung, Range-Requests oder Sicherheitspolitiken. Ergänzend pflegt IANA die HTTP Field Name Registry und related Registries. Für ein Referenzwerk ist diese Trennung relevant: Ein Feldname kann verbreitet sein, aber ohne klare Standardspezifikation abweichende Semantik in Zwischenstationen erzeugen. Umgekehrt kann ein standardisierter Header durch „HTTP Caching“ oder Browser-Sicherheitsmodelle zusätzliche, nicht rein RFC-getriebene Praxisregeln erhalten, die sich jedoch stets an den normativen Text anlehnen müssen.

Bei der Einordnung hilft eine saubere Referenzierung der Quelle pro Header: Semantik-Quelle (welcher RFC definiert Bedeutung und Syntax), Transport-Quelle (welcher RFC regelt Übertragung/Verbote in HTTP/2/3), sowie Registry-Status (permanent/provisional, obsolet). Für Implementierungen ist außerdem wichtig, ob ein Header durch „intermediary transformations“ beeinflusst werden darf. Einige Felder sind ausdrücklich nicht transformierbar, andere nur unter bestimmten Bedingungen. Diese Differenz entscheidet darüber, ob ein CDN komprimieren, normalisieren oder Header umsortieren darf, ohne die Bedeutung zu verändern.

Katalog der Request- und Response-Header: Richtung, RFC-Quelle, Datentyp, Beispielwerte, Sicherheits- und Caching-Wirkung, Kompatibilität

Ein belastbarer Header-Katalog braucht konsistente Metadaten: Richtung (Request/Response), normative Quelle (RFC und Abschnitt), Datentyp bzw. Grammatik (z. B. Token, Quoted-String, HTTP-Date), typische Beispielwerte sowie eine Einordnung nach Sicherheitswirkung, Cache-Semantik, Proxy/CDN-Verhalten und Interaktionen. Viele Felder sind in RFC 9110 (HTTP Semantics) und RFC 9111 (HTTP Caching) definiert; einzelne Mechanismen (z. B. CORS, Cookies, Structured Fields) liegen in eigenständigen RFCs. Zusätzlich existieren de-facto Header, die nicht standardisiert sind; sie sollten klar als proprietär markiert werden, weil ihre Verarbeitung zwischen Implementierungen variiert.

Auszeichnungs- und Datentyp-Konventionen (Syntax)

HTTP-Headerfelder sind name/value-basiert; Feldnamen sind ASCII und case-insensitive. Für viele sicherheits- und cache-relevante Header sind ABNF-Regeln in den RFCs festgelegt. Moderne Spezifikationen setzen zunehmend auf „Structured Fields“ (RFC 8941), die klare Typen wie Boolean, Integer, String, Token, Byte Sequence, List und Dictionary definieren. Das vereinfacht robustes Parsing, reduziert Ambiguität und verbessert Interoperabilität zwischen User-Agents, Proxys und Origin-Servern.

Bei klassischen Headern dominieren Tokens und Parameterlisten (z. B. Cache-Control: max-age=60, must-revalidate), während Datumsfelder das HTTP-Date-Format nutzen (z. B. Expires, If-Modified-Since). Für Referenzwerte sollten Beispiele stets syntaktisch korrekt sein (keine lokalen Datumsformate, keine nicht erlaubten Anführungszeichen) und den jeweiligen Kontext abbilden, etwa mehrere Direktiven in Cache-Control oder ein stark/weak Validator-Präfix in ETag.

• Token/Parameterlisten: Direktiven und Parameter werden üblicherweise kommasepariert notiert, z. b. Cache-Control: public, max-age=300, stale-while-revalidate=30.
• HTTP-Date: Datumswerte verwenden das IMF-fixdate-Format, z. b. Expires: Wed, 21 Oct 2015 07:28:00 GMT.
• Validatoren: Entity-Tag-Werte sind quoted, optional weak, z. b. ETag: "abc123" oder ETag: W/"abc123".
• Structured Fields: maschinenlesbare Typen nach RFC 8941, z. b. Sec-Fetch-Site: same-origin (Token) oder Permissions-Policy: geolocation=() (Policy-Syntax, nicht RFC 8941, aber strikt spezifiziert).

Katalog-Ausschnitt: repräsentative Header mit Metadaten

Die folgende Tabelle ist ein exemplarischer Ausschnitt. Sie zeigt, wie sich Richtung, RFC-Bezug, Werttyp, typische Werte sowie Sicherheits- und Caching-Effekte zusammenführen lassen. In einem vollständigen Referenzkatalog werden zusätzlich Interaktionshinweise (z. b. „überschreibt/ergänzt“) und Kompatibilitätsnoten (z. b. „Hop-by-hop“, „nur HTTPS“, „Browser-abhängig“) pro Header gepflegt.

Einordnung: Sicherheitswirkung vs. Caching-Semantik

Sicherheitswirkung entsteht entweder durch Transport- und Policy-Kontrollen (z. b. HSTS, CSP, Permissions Policy) oder durch Schutz vor unerwünschter Persistenz und Wiederverwendung von Antworten (z. b. Cache-Control: no-store bei sensitiven Ressourcen). Caching-Semantik wird primär durch Cache-Control, Expires, Validatoren (ETag, Last-Modified) und Variantentrennung (Vary) bestimmt. In Shared Caches (CDN, Forward Proxy) entscheidet zusätzlich, ob eine Antwort als öffentlich teilbar gilt; missverständliche Kombinationen können zu Datenlecks führen, etwa wenn personalisierte Antworten ohne private oder ohne ausreichendes Vary ausgeliefert werden.

• Persistenz unterbinden: Cache-Control: no-store verhindert Speicherung in Caches; geeignet für Antworten mit Credentials, PII oder One-Time-Tokens.
• Revalidierung erzwingen: Cache-Control: no-cache erlaubt Speicherung, verlangt aber Revalidierung vor Wiederverwendung; in Shared Caches oft mit ETag oder Last-Modified kombiniert.
• Shared-Cache explizit steuern: Cache-Control: s-maxage=600 priorisiert TTL in Shared Caches gegenüber max-age; in CDNs relevant, wenn Browser kürzer cachen sollen.
• Variantentrennung absichern: Vary: Accept-Encoding verhindert, dass eine komprimierte Variante fälschlich für Clients ohne passenden Decoder wiederverwendet wird; Vary: Origin oder Vary: Cookie kann erforderlich sein, ist aber cache-fragmentierend.

Kompatibilität und Interoperabilität in Proxys/CDNs

Kompatibilitätsnoten sollten zwischen End-to-End-Headern und Hop-by-hop-Headern trennen. Hop-by-hop-Felder (klassisch über Connection benannt) gelten nur für eine Transportverbindung und dürfen nicht weitergeleitet werden; HTTP/2 und HTTP/3 verbieten solche Mechanismen weitgehend auf der Header-Ebene, weil Verbindungsdetails anders modelliert sind. Für CDNs und Reverse Proxys ist außerdem entscheidend, welche Header in den Cache-Key einfließen (häufig konfigurierbar) und welche Header als „cache-busting“ interpretiert werden (z. b. Authorization, Cookie). Ein Katalog sollte daher neben RFC-Konformität auch praktische Defaults dokumentieren, ohne proprietäre Regeln als Standard auszugeben.

Bei Sicherheitsheadern ist die Kompatibilität primär clientseitig: Browser implementieren Policies unterschiedlich schnell und teilweise mit abweichenden Directive-Namen. Bei Cache-Headern liegt die Varianz eher in Zwischenspeichern: Shared Caches müssen RFC 9111 folgen, können aber Obergrenzen, Heuristiken oder administrative Overrides anwenden. Solche Overrides sollten als Umgebungseigenschaft beschrieben werden, nicht als Eigenschaft des Headers selbst.

Interaktionsmatrix und Edge-Praxis: Cache-Control/ETag/Expires/Pragma-Kombinationen, Vary/Content-Negotiation sowie Auswirkungen auf Proxy- und CDN-Caches

HTTP-Caching entsteht aus dem Zusammenspiel mehrerer Header-Familien: Freshness (z. b. Cache-Control, Expires), Validierung (z. b. ETag, Last-Modified), Transportbedingungen (z. b. Age) und Schlüsselbildung für Varianten (insbesondere Vary). In Edge-Umgebungen wirken zusätzlich Heuristiken, Normalisierungen und Policy-Layer von Proxies und CDNs. Daraus ergeben sich Interaktionen, die sich nicht als „ein Header entscheidet“ beschreiben lassen, sondern als deterministische Prioritäten plus Implementierungsdetails.

Prioritätenmodell: Freshness vs. Validierung (HTTP Semantics)

Für Caches steht zuerst die Frage im Raum, ob eine Response frisch ist. Freshness berechnet sich primär aus Cache-Control-Direktiven wie max-age oder s-maxage (für Shared Caches). Expires dient als älterer, datumsgestützter Fallback, wird aber in der Praxis durch Cache-Control übersteuert, wenn beides vorhanden ist. Ist eine Response nicht frisch, folgt die zweite Frage: lässt sie sich revalidieren? Dann kommen Validatoren ins Spiel: ETag in Verbindung mit If-None-Match (starker/ schwacher Validator) oder Last-Modified in Verbindung mit If-Modified-Since. Revalidierung kann Bandbreite sparen, ändert aber nicht die Cache-Schlüsselbildung: Varianten bleiben Varianten.

Pragma: no-cache ist historisch für HTTP/1.0 und wird heute primär als Request-Hinweis interpretiert. Moderne Caches orientieren sich an Cache-Control: no-cache (Request oder Response), das präziser definiert ist. In Mischlandschaften (Legacy-Proxies, Appliances) kann Pragma dennoch relevant bleiben; eine doppelte Setzung (Cache-Control: no-cache plus Pragma: no-cache) wird deshalb häufig als Kompatibilitätsmaßnahme eingesetzt, ohne semantisch zusätzliche Wirkung in HTTP/1.1+ zu garantieren.

Interaktionsmatrix: Cache-Control, Expires und Pragma als Entscheidungsbaum

Für Freshness gilt in der Praxis folgende Hierarchie: Cache-Control-Direktiven bestimmen die Lebensdauer; Expires wird als Fallback ausgewertet, wenn keine explizite Freshness aus Cache-Control ableitbar ist. Pragma beeinflusst primär Requests und dient als Kompatibilitätssignal. Zusätzlich verändern Direktiven die Zulässigkeit der Speicherung: private verhindert das Speichern in Shared Caches, erlaubt aber Browser-Caching; public kann Responses, die sonst nicht in Shared Caches gespeichert würden (z. B. weil sie eine Authorization-Anfrage beantwortet haben), für Shared Caches explizit freigeben, sofern keine anderen Verbote greifen.

• Freshness-Basis: Cache-Control: s-maxage=... (Shared Cache) hat Vorrang vor Cache-Control: max-age=...; fehlen beide, wird häufig Expires: ... herangezogen.
• Revalidierungszwang: Cache-Control: no-cache erlaubt Speicherung, erzwingt aber Revalidierung vor Wiederverwendung; mit ETag wird daraus typischerweise ein If-None-Match-Workflow mit 304.
• Speicherverbot: Cache-Control: no-store untersagt das Schreiben in Caches; auch ein vorhandenes ETag hilft dann nicht, weil es keinen Cache-Eintrag geben darf.
• Legacy-Request-Signale: Pragma: no-cache wird bei Requests oft als „nicht aus Cache bedienen“ interpretiert; robuste Steuerung erfolgt über Cache-Control: no-cache oder Cache-Control: max-age=0 im Request.
• Übersteuerungsfallen: Ein Response-Mix aus Cache-Control: max-age=0 und weit in der Zukunft liegendem Expires führt trotz „schönem Datum“ zu sofortiger Staleness, weil Cache-Control die Freshness festlegt.

ETag an der Edge: Validator-Stabilität, Recompression und Cache-Key

ETag-Werte müssen über alle Instanzen hinweg stabil sein, wenn Shared Caches revalidieren sollen. Instabile ETags (z. b. mit Zeitstempel, non-deterministischer Serialisierung oder Knotenspezifika) erhöhen die Rate an 200-Antworten bei eigentlich unverändertem Inhalt. Zusätzlich kollidiert ETag mit Edge-Transformationen: Komprimierung oder Bild-/HTML-Optimierung kann den Body verändern, während der Origin-ETag unverändert durchgereicht wird. Dann schlagen If-None-Match-Vergleiche fehl, obwohl der semantische Inhalt identisch ist. Abhilfe entsteht nur durch konsequente End-to-End-Strategie: Entweder keine Body-Transformation in Shared Caches für ETag-geschützte Objekte, oder ETag-Erzeugung auf der finalen Repräsentation (inklusive Content-Coding) beziehungsweise Nutzung schwacher Validatoren, wenn das Modell es erlaubt.

Für Varianten gilt: Ein Cache kann denselben URL-Pfad mehrfach speichern, wenn Vary die Schlüsselbildung erweitert. Das ist kein Randthema, sondern ein Hauptgrund für unerwartete Cache-Misses: Ein Objekt mit Vary: Accept-Encoding erzeugt mindestens getrennte Einträge für gzip/br/identity, abhängig davon, welche Encodings ein Client (oder ein vorgelagerter Proxy) anbietet. Bei CDNs kommt hinzu, dass manche Plattformen Accept-Encoding normalisieren oder selbst wählen; dadurch kann Vary entweder redundant werden oder, bei unglücklicher Konfiguration, zu einer Cache-Fragmentierung führen.

Vary und Content Negotiation: Korrektheit vor Hit-Rate

Vary schützt vor dem Ausliefern falscher Repräsentationen aus dem Cache. Das gilt für klassische Content Negotiation über Accept (z. b. JSON vs. HTML), Accept-Language (Sprache), Accept-Encoding (Komprimierung) und für CORS-abhängige Antworten, sofern eine Variation tatsächlich stattfindet. Eine überbreite Variation ist jedoch ein direkter Multiplikator auf den Cache-Key und senkt die Wiederverwendungswahrscheinlichkeit. Besonders kritisch ist Vary: User-Agent: Der Header ist hochgradig divers, ändert sich häufig und führt in Shared Caches schnell zu einer faktischen Deaktivierung des Nutzens. Für Geräteanpassungen ist eine separate URL-Strategie oder serverseitige Feature-Detection oft robuster.

Shared Caches, CDNs und Forward Proxies: Age, Revalidation und Coalescing

In Shared Caches signalisiert Age die seit der Generierung oder erfolgreichen Validierung vergangene Zeit im Cache. Diese Zeit zählt zur Freshness-Berechnung hinzu, wodurch ein Objekt früher stale werden kann als der Origin es aus Sicht eines einzelnen Clients „gefühlt“ erwarten lässt. Bei Revalidierung ist entscheidend, ob der Cache conditional Requests weiterleitet oder selbst terminiert. Viele CDNs reduzieren Origin-Last mit Request-Coalescing: Wenn viele Clients gleichzeitig ein stale Objekt anfragen, sendet die Edge nur eine Revalidierung, während weitere Requests warten. Das Verhalten ist produkt- und policy-abhängig; semantisch bleibt der Mechanismus ein Spezialfall von „stale, dann validate“.

Forward Proxies (Unternehmensnetze) verändern die Lage zusätzlich, weil Requests aktiv Cache-Bypass-Signale tragen können, etwa Cache-Control: no-cache oder Cache-Control: max-age=0. Eine Response-Strategie, die ausschließlich auf „lange Freshness“ setzt, kann dadurch ausgehebelt werden. Robust werden Konfigurationen, wenn sie Korrektheit über Validatoren absichern (ETag/Last-Modified) und sensible Inhalte mit Cache-Control: private oder Cache-Control: no-store abgrenzen, statt auf implizite Annahmen über die Infrastruktur zu bauen.