2.1. HTTP Fields (HTTP-Felder)
2.1. HTTP Fields (HTTP-Felder)
Der Komponentenname für ein HTTP-Feld ist die in Kleinbuchstaben geschriebene Form seines Feldnamens gemäß Abschnitt 5.1 von [HTTP]. Obwohl HTTP-Feldnamen groß-/kleinschreibungsunabhängig sind, MÜSSEN Implementierungen Kleinbuchstaben verwenden (z. B. content-type, date, etag), wenn sie als Komponentennamen dienen.
Der Komponentenwert eines HTTP-Feldes ist der Feldwert gemäß Abschnitt 5.5 von [HTTP]. Der Feldwert MUSS aus dem benannten Header-Feld der Zielnachricht stammen, sofern dies nicht durch zusätzliche Parameter und Regeln (z. B. die Flags req und tr, unten) überschrieben wird. Für die meisten Felder ist der Feldwert eine ASCII-Zeichenkette wie von [HTTP] empfohlen, und der Komponentenwert ist genau diese Zeichenkette. Andere Kodierungen können in Implementierungen vorkommen; alle nicht-ASCII-Feldwerte MÜSSEN vor Aufnahme in die Signaturbasis nach ASCII kodiert werden. Der Parameter bs (Abschnitt 2.1.3) bietet ein Verfahren zum Einpacken problematischer Feldwerte.
Sofern nicht durch zusätzliche Parameter und Regeln überschrieben, MÜSSEN HTTP-Feldwerte gemäß Abschnitt 5.2 von [HTTP] zu einem einzelnen Wert zusammengeführt werden. Mehrfach gesendete Felder MÜSSEN durch Verkettung der Werte mit genau einem Komma und einem Leerzeichen als Trenner (, + ) kombiniert werden. Vermittler dürfen Werte mit beliebigem Whitespace zwischen den Kommas zusammenführen; berücksichtigt der Verifizierende das nicht, kann die Signatur fehlschlagen, weil Signierender und Verifizierender unterschiedliche Komponentenwerte in ihrer Signaturbasis sehen. Zur Robustheit wird EMPFOHLEN, signierte Nachrichten nur eine Instanz jedes abgedeckten Feldes zu enthalten, insbesondere mit für Listenfelder nach dem untenstehenden Algorithmus serialisiertem Wert. So bleibt der Feldwert eher von Vermittlern unangetastet. Wo das nicht möglich ist und mehrere Instanzen getrennt gesendet werden müssen, wird EMPFOHLEN, dass Signierende und Verifizierende listenbasierte Felder verarbeiten, indem alle Einzelwerte nach dem strengen Algorithmus unten kombiniert werden, um Vermittlerverhalten abzufedern. Handelt es sich um ein Structured Field vom Typ List oder Dictionary, kann dies direkter durch strenge Structured-Field-Serialisierung erreicht werden (Abschnitt 2.1.1).
Einige HTTP-Felder wie Set-Cookie [COOKIE] folgen keiner Syntax, die eine eindeutige Kombination mehrerer Feldwerte erlaubt. Obwohl der Komponentenwert im Signaturprozess nicht geparst wird und nur Teil der Signaturbasis ist (Abschnitt 2.5), ist Vorsicht geboten, da der kombinierte Wert mehrdeutig sein kann. Der Parameter bs (Abschnitt 2.1.3) hilft dabei. Siehe Abschnitt 7.5.6.
Ist der korrekt kombinierte Wert in einer Implementierung nicht direkt verfügbar, liefert folgender Algorithmus kanonisierte Ergebnisse für listenbasierte Felder:
-
Erzeuge eine geordnete Liste der Feldwerte jeder Instanz des Feldes in der Reihenfolge ihres Vorkommens in der Nachricht.
-
Entferne führenden und nachfolgenden Whitespace von jedem Listeneintrag. Da HTTP-Feldwerte keinen solchen Whitespace enthalten dürfen, ist dies in konformer Implementierung eine No-Op.
-
Entferne veraltetes Zeilenumbrechen (obsolete line folding) in der Zeile und ersetze es durch ein einzelnes Leerzeichen (
-
Verkette die Werte mit genau einem Komma (
,) und einem Leerzeichen (
Die resultierende Zeichenkette ist der Komponentenwert.
Einige Felder haben mehrere semantisch äquivalente Serialisierungen (z. B. groß-/kleinschreibungsunabhängige Werte, die Vermittler ändern könnten). Anwendungen, die solche Felder signieren und verarbeiten, MÜSSEN sicherstellen, dass Signierender und Verifizierender denselben Wert ableiten (Abschnitt 7.5.2).
Folgende nicht normative Beispiele zeigen Komponentenwerte für Header-Felder anhand dieses HTTP-Fragmentes:
Host: www.example.com
Date: Tue, 20 Apr 2021 02:07:56 GMT
X-OWS-Header: Leading and trailing whitespace.
X-Obs-Fold-Header: Obsolete
line folding.
Cache-Control: max-age=60
Cache-Control: must-revalidate
Example-Dict: a=1, b=2;x=1;y=2, c=(a b c)
Im Signaturbasis-Format (Abschnitt 2.5):
"host": www.example.com
"date": Tue, 20 Apr 2021 02:07:56 GMT
"x-ows-header": Leading and trailing whitespace.
"x-obs-fold-header": Obsolete line folding.
"cache-control": max-age=60, must-revalidate
"example-dict": a=1, b=2;x=1;y=2, c=(a b c)
Leere HTTP-Felder können signiert werden, wenn sie vorhanden sind. Der kanonisierte Wert ist die leere Zeichenkette. Das folgende leere Header-Feld mit (SP) für ein nachfolgendes Leerzeichen vor dem leeren Feldwert:
X-Empty-Header:(SP)
wird vom Algorithmus zur Signaturbasis-Erzeugung (Abschnitt 2.5) mit leerem String nach Doppelpunkt und Leerzeichen nach dem Komponenten-Identifikator serialisiert:
"x-empty-header":(SP)
HTTP-Feld-Komponenten-Identifikatoren KÖNNEN in bestimmten Fällen folgende Parameter haben:
sf Boolesches Flag: Komponentenwert wird mit strenger Kodierung des Structured-Field-Wertes serialisiert (Abschnitt 2.1.1).
key String-Parameter: wählt ein einzelnes Mitglied aus einem Dictionary Structured Field (Abschnitt 2.1.2).
bs Boolesches Flag: Einzelwerte werden als Byte-Sequenzen (Byte Sequence) kodiert, bevor sie kombiniert werden (Abschnitt 2.1.3).
req Boolesches Flag bei signierten Antworten: Wert stammt aus der auslösenden Anfrage, nicht direkt aus der Antwort. Gilt auch für abgeleitete Komponenten-Identifikatoren mit Anfrageziel (Abschnitt 2.4).
tr Boolesches Flag: Feldwert aus Trailer-Feldern gemäß Abschnitt 6.5 von [HTTP]. Fehlt das Flag, stammt der Wert aus Header-Feldern gemäß Abschnitt 6.3 von [HTTP] (Abschnitt 2.1.4).
Mehrere Parameter KÖNNEN gemeinsam angegeben werden; einige Kombinationen sind redundant oder inkompatibel. Z. B. deckt sf bei Dictionary mit key bereits ab, da key strenge Serialisierung erfordert. bs (Rohbytes) ist nicht verträglich mit sf oder key (geparste Strukturen nach Kombination).
Weitere Parameter können im Register „HTTP Signature Component Parameters“ (Abschnitt 6.5) definiert werden.