1.3. HTTP Message Transformations (HTTP-Nachrichtentransformationen)
1.3. HTTP Message Transformations (HTTP-Nachrichtentransformationen)
HTTP erlaubt und erfordert mitunter Transformationen; Implementierungen müssen viele tolerieren. Folgende nicht normative, unvollständige Liste dient als Kontext:
-
Umordnung von Feldern mit unterschiedlichen Namen (Abschnitt 5.3 von [HTTP]).
-
Zusammenführung gleichnamiger Felder (Abschnitt 5.2 von [HTTP]).
-
Entfernung von Feldern aus
Connection(Abschnitt 7.6.1 von [HTTP]). -
Hinzufügen von Steuerfeldern (Abschnitt 7.6.1 von [HTTP]).
-
Hinzufügen oder Entfernen von Transfer-Codierungen (Abschnitt 7.7 von [HTTP]).
-
Felder wie
Via(Abschnitt 7.6.3 von [HTTP]) undForwarded(Abschnitt 4 von [RFC7239]). -
Wechsel der HTTP-Version (z. B. HTTP/1.x ↔ HTTP/2).
-
Groß-/Kleinschreibung bei groß-/kleinschreibungsunabhängigen Teilen (Feldnamen, Schema, Host).
-
Änderungen an Request Target und Authority ohne Änderung der Ziel-URI (Abschnitt 7.1 von [HTTP]).
Veraltete oder unzulässige, aber vorkommende Transformationen können die Signatur dennoch erlauben:
- Whitespace an Feldwertgrenzen;
obs-foldin Feldwerten (Abschnitt 5.2 von [HTTP/1.1]).
Solche Änderungen an abgedeckten Komponenten sollten die Verifikation nicht verhindern; Änderungen an nicht abgedeckten ebenfalls nicht. Beispiele: Anhang B.4.
Parsen/Neu-Serialisieren abgedeckter Feldwerte oder Ändern abgeleiteter Komponenten kann die Validität zerstören. Anwendungen müssen abgedeckte Komponenten so wählen, dass erwartete Transformationen abgedeckt sind.