Zum Hauptinhalt springen

1. Introduction (Einführung)

Die Festlegung der Syntax neuer HTTP-Header- (header) und Trailer-Felder (trailer) ist eine aufwändige Aufgabe. Selbst mit der Anleitung aus Abschnitt 8.3.1 von [RFC7231] gibt es für potenzielle HTTP-Feldautoren noch viele Entscheidungen und Fallstricke.

Sobald ein Feld definiert ist, müssen in der Regel eigene Parser und Serialisierer geschrieben werden, da jeder Feldwert eine scheinbar allgemeine Syntax geringfügig anders behandelt.

Dieses Dokument führt eine Reihe gemeinsamer Datenstrukturen für die Definition neuer HTTP-Feldwerte ein, um diese Probleme zu lösen. Insbesondere definiert es ein gemeinsames abstraktes Modell für diese Datenstrukturen sowie eine konkrete Serialisierung zur Darstellung dieses Modells in HTTP [RFC7230]-Header- und Trailer-Feldern.

HTTP-Felder, die als „Strukturierter Header (Structured Header)" oder „Strukturierter Trailer (Structured Trailer)" definiert sind (oder als „Strukturiertes Feld (Structured Field)", wenn das Feld beides sein kann), verwenden die in dieser Spezifikation definierten Typen, um ihre Syntax und grundlegenden Verarbeitungsregeln festzulegen. Dies vereinfacht sowohl die Arbeit der Spezifikationsautoren als auch die Verarbeitung durch Implementierer.

Darüber hinaus können zukünftige HTTP-Versionen alternative Serialisierungen dieser strukturierten abstrakten Modelle definieren, sodass Felder, die dieses Modell verwenden, effizienter übertragen werden können, ohne neu definiert werden zu müssen.

Zu beachten ist, dass das Ziel dieses Dokuments nicht darin besteht, die Syntax bestehender HTTP-Felder neu zu definieren; die hier beschriebenen Mechanismen gelten nur für Felder, die sich ausdrücklich dafür entscheiden, sie zu verwenden.

Abschnitt 2 beschreibt, wie strukturierte Felder spezifiziert werden.

Abschnitt 3 definiert die verschiedenen abstrakten Datentypen, die in strukturierten Feldern verwendet werden können.

Diese abstrakten Typen können mithilfe der in Abschnitt 4 beschriebenen Algorithmen in HTTP-Feldwerte serialisiert oder aus diesen geparst werden.

1.1 Intentionally Strict Processing (Bewusst strenge Verarbeitung)​

Diese Spezifikation definiert bewusst strenge Parse- und Serialisierungsverhalten mithilfe schrittweiser Algorithmen; die einzige definierte Fehlerbehandlung besteht darin, die Operation vollständig fehlschlagen zu lassen.

Dies soll eine korrekte Implementierung und gute Interoperabilität fördern. Implementierungen, die versuchen zu „helfen", indem sie bei der Eingabe toleranter sind, verschlechtern die Interoperabilität tatsächlich, da sie andere Implementierungen unter Druck setzen, ähnliche (aber möglicherweise subtil unterschiedliche) Workarounds zu implementieren.

Mit anderen Worten: Strenge Verarbeitung ist ein bewusstes Merkmal dieser Spezifikation; sie ermöglicht die frühzeitige Erkennung und Korrektur nicht konformer Eingaben und vermeidet mögliche Interoperabilitäts- und Sicherheitsprobleme.

Zu beachten ist, dass aufgrund dieser Strenge, wenn ein Feld von mehreren Parteien angehängt wird (z. B. von Zwischenproxys oder verschiedenen Komponenten des Senders), ein Fehler im Wert einer Partei dazu führen kann, dass der gesamte Feldwert nicht geparst werden kann.

1.2 Notational Conventions (Notationskonventionen)​

Die Schlüsselwörter „MUST" (MUSS), „MUST NOT" (DARF NICHT), „REQUIRED" (ERFORDERLICH), „SHALL" (SOLL), „SHALL NOT" (SOLL NICHT), „SHOULD" (SOLLTE), „SHOULD NOT" (SOLLTE NICHT), „RECOMMENDED" (EMPFOHLEN), „NOT RECOMMENDED" (NICHT EMPFOHLEN), „MAY" (KANN) und „OPTIONAL" (OPTIONAL) in diesem Dokument sind gemäß BCP 14 [RFC2119] [RFC8174] zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen (wie hier gezeigt).

Dieses Dokument verwendet Algorithmen zur Spezifikation von Parse- und Serialisierungsverhalten sowie die Augmented Backus-Naur Form (ABNF)-Notation aus [RFC5234], um die erwartete Syntax in HTTP-Headerfeldern zu veranschaulichen. Dabei werden die Regeln VCHAR, SP, DIGIT, ALPHA und DQUOTE aus [RFC5234] verwendet. Außerdem werden die Regeln tchar und OWS aus [RFC7230] einbezogen.

Beim Parsen aus HTTP-Feldern MÜSSEN (MUST) Implementierungen ein Verhalten aufweisen, das von der Befolgung der Algorithmen nicht zu unterscheiden ist. Bei Abweichungen zwischen dem Parse-Algorithmus und der ABNF hat der angegebene Algorithmus Vorrang.

Für die Serialisierung in HTTP-Felder veranschaulicht die ABNF deren erwartete Darstellung auf der Leitung, und die Algorithmen definieren die empfohlene Methode zur Erzeugung dieser Darstellung. Implementierungen KÖNNEN (MAY) vom angegebenen Verhalten abweichen, solange die Ausgabe noch korrekt durch den in Abschnitt 4.2 beschriebenen Parse-Algorithmus verarbeitet werden kann.

Wesentliche Erkenntnisse (Key Takeaways)​

1. Problemhintergrund​

Schwachstellen bei der Definition herkömmlicher HTTP-Felder:

# Jedes Feld hat seine eigene Syntax:
Cache-Control: max-age=3600, private
Accept: text/html, application/json;q=0.9
Content-Type: text/html; charset=utf-8
Link: `https://example.com`; rel="preload"

# Folge:
- Jedes Feld benötigt einen eigenen Parser
- Scheinbar ähnliche Syntaxen weisen subtile Unterschiede auf
- Fehleranfällig und schwer zu warten

2. Lösung​

Strukturierte Felder bieten:

  • ✅ Einheitliche Datentypen: Integer, String, Boolean, List, Dictionary usw.
  • ✅ Standardisierte Serialisierung: Konsistente Formatregeln
  • ✅ Eindeutige Parse-Algorithmen: Beseitigung von Mehrdeutigkeiten
  • ✅ Vorwärtskompatibilität: Zukünftig können effizientere Kodierungen verwendet werden

3. Strenge-Philosophie​

❌ Falsches Beispiel – toleranter Parser:
Eingabe: key="value   (fehlende schließende Anführungszeichen)
Tolerantes Parsen: Anführungszeichen automatisch ergänzen, Parsen erfolgreich

Problem:
- Verschiedene Implementierungen können unterschiedliche „Korrekturen" vornehmen
- Führt zu unvorhersehbarem Verhalten
- Erzeugt Sicherheitslücken

✓ Richtiges Beispiel – strenger Parser:
Eingabe: key="value   (fehlende schließende Anführungszeichen)
Strenges Parsen: Sofortiger Abbruch, Fehler zurückgeben

Vorteile:
- Erzwingt korrekte Formatierung beim Erzeuger
- Stellt sicheres Verhalten aller Implementierungen sicher
- Probleme werden frühzeitig erkannt

4. Designziele​

  • Keine Neudefinition bestehender Felder: Nur für neue Felder
  • Abstrakt + Konkret: Abstraktes Modell + HTTP/1.1-Serialisierung
  • Zukunftssicher: Neue Serialisierungen für HTTP/2, HTTP/3 definierbar

5. Dokumentstruktur​

Abschnitt 2: Wie strukturierte Felder definiert werden → Leitfaden für Spezifikationsautoren
Abschnitt 3: Abstrakte Datentypen → List, Dictionary, Item usw.
Abschnitt 4: Serialisierungs- und Parse-Algorithmen → Konkrete Implementierungsdetails

Praktische Auswirkungen​

Für Spezifikationsautoren​

Herkömmliche Methode:
---------
Neues Feld "Example-Field" definieren
- Eigene ABNF-Syntax schreiben
- Parse-Regeln detailliert beschreiben
- Randfälle behandeln
- Fehlerbehandlung definieren
(Kann Dutzende Seiten Dokumentation erfordern)

Methode mit strukturierten Feldern:
-------------
Neues Feld "Example-Field" definieren
- RFC 8941 referenzieren
- Als Dictionary-Typ angeben
- Bedeutung von Schlüsseln und Werten definieren
(Möglicherweise nur wenige Absätze erforderlich)

Für Implementierer​

// Herkömmliche Methode – jedes Feld benötigt einen eigenen Parser
function parseCacheControl(value) {
  // 50-100 Zeilen Code...
}
function parseAccept(value) {
  // Weitere 50-100 Zeilen Code...
}
function parseContentType(value) {
  // Nochmals 50-100 Zeilen Code...
}

// Methode mit strukturierten Feldern – allgemeiner Parser
const cacheControl = parseDictionary(header);  // Wiederverwendbar
const accept = parseList(header);             // Wiederverwendbar
const contentType = parseItem(header);        // Wiederverwendbar

Für die Netzwerkeffizienz​

HTTP/1.1: Textformat
Example-Dict: a=1, b=2, c=3

HTTP/2 (zukünftig): Mögliche Binärkodierung
[0x01] [dict] [3 items] [a:1] [b:2] [c:3]
↑ Kompakter, aber logisch identisch

Anwendungsfälle​

✓ Strukturierte Felder sollten verwendet werden​

  • Bei der Definition neuer HTTP-Header
  • Wenn komplexe Datenstrukturen benötigt werden (Listen, Wörterbücher)
  • Wenn zukünftig effizientere Kodierungen unterstützt werden sollen
  • Wenn gute Interoperabilität angestrebt wird

✗ Strukturierte Felder sollten nicht verwendet werden​

  • Für bereits definierte bestehende Felder (z. B. Cache-Control)
  • Für einfache Einzelwertfelder (möglich, aber nicht zwingend)
  • Für Felder, die Abwärtskompatibilität mit älteren Clients erfordern
Letztes Update am