5. Nachrichten-Routing
Das Routing von HTTP-Anforderungsnachrichten wird von jedem Client basierend auf der Zielressource, der Proxy-Konfiguration des Clients und dem Aufbau oder der Wiederverwendung einer inbound-Verbindung bestimmt. Das entsprechende Antwort-Routing folgt derselben Verbindungskette zurück zum Client.
5.1. Identifizierung einer Zielressource
HTTP wird in einer Vielzahl von Anwendungen eingesetzt, von Universalcomputern bis hin zu Haushaltsgeräten. In einigen Fällen sind Kommunikationsoptionen in der Konfiguration eines Clients fest einprogrammiert. Die meisten HTTP-Clients verlassen sich jedoch auf denselben Ressourcenidentifikationsmechanismus und dieselben Konfigurationstechniken wie universelle Webbrowser.
HTTP-Kommunikation wird von einem User Agent zu einem bestimmten Zweck initiiert. Der Zweck ist eine Kombination aus der Anforderungssemantik, die in [RFC7231] definiert ist, und einer Zielressource, auf die diese Semantik angewendet werden soll. Eine URI-Referenz (Abschnitt 2.7) wird typischerweise als Bezeichner für die "Zielressource" verwendet, die ein User Agent in ihre absolute Form auflösen würde, um den "Ziel-URI" zu erhalten. Der Ziel-URI schließt die Fragmentkomponente der Referenz (falls vorhanden) aus, da Fragmentbezeichner für die clientseitige Verarbeitung reserviert sind ([RFC3986], Abschnitt 3.5).
5.2. Eingehende Verbindung
Sobald der Ziel-URI bestimmt ist, muss ein Client entscheiden, ob eine Netzwerkanfrage notwendig ist, um die gewünschte Semantik zu erreichen, und wenn ja, wohin diese Anfrage gerichtet werden soll.
Wenn der Client einen Cache hat [RFC7234] und die Anfrage davon erfüllt werden kann, wird die Anfrage üblicherweise zuerst dorthin gerichtet.
Wird die Anfrage nicht von einem Cache erfüllt, prüft ein typischer Client seine Konfiguration, um zu bestimmen, ob ein Proxy zur Erfüllung der Anfrage verwendet werden soll. Die Proxy-Konfiguration ist implementierungsabhängig, basiert aber häufig auf URI-Präfixabgleich, selektivem Authority-Abgleich oder beidem, und der Proxy selbst wird üblicherweise durch einen "http"- oder "https"-URI identifiziert. Ist ein Proxy anwendbar, stellt der Client eine inbound-Verbindung her, indem er eine Verbindung zu diesem Proxy aufbaut (oder wiederverwendet).
Ist kein Proxy anwendbar, ruft ein typischer Client eine Handler-Routine auf, die üblicherweise spezifisch für das Schema des Ziel-URI ist, um sich direkt mit einer Authority für die Zielressource zu verbinden. Wie dies erreicht wird, hängt vom Schema des Ziel-URI ab und ist durch die zugehörige Spezifikation definiert, ähnlich wie diese Spezifikation den Zugriff auf den Ursprungsserver für die Auflösung der Schemata "http" (Abschnitt 2.7.1) und "https" (Abschnitt 2.7.2) definiert.
HTTP-Anforderungen bezüglich der Verbindungsverwaltung sind in Abschnitt 6 definiert.
5.3. Anfrageziel
Sobald eine inbound-Verbindung erhalten wurde, sendet der Client eine HTTP-Anfragenachricht (Abschnitt 3) mit einem Anfrageziel, das vom Ziel-URI abgeleitet ist. Es gibt vier verschiedene Formate für das Anfrageziel, abhängig sowohl von der angefragten Methode als auch davon, ob die Anfrage an einen Proxy geht.
request-target = origin-form
/ absolute-form
/ authority-form
/ asterisk-form
5.3.1. origin-form
Die gebräuchlichste Form des Anfrageziels ist die origin-form.
origin-form = absolute-path [ "?" query ]
Bei einer Anfrage direkt an einen Ursprungsserver, außer einer CONNECT- oder einer serverweiten OPTIONS-Anfrage (wie unten ausgeführt), muss ein Client als Anfrageziel nur die absolute Pfad- und Query-Komponente des Ziel-URI senden. Ist die Pfadkomponente des Ziel-URI leer, muss der Client "/" als Pfad innerhalb der origin-form des Anfrageziels senden. Ein Header-Feld Host wird ebenfalls gesendet, wie in Abschnitt 5.4 definiert.
Beispielsweise würde ein Client, der eine Repräsentation der Ressource abrufen möchte, die identifiziert ist als
http://www.example.org/where?q=now
direkt vom Ursprungsserver, eine TCP-Verbindung zu Port 80 des Hosts "www.example.org" öffnen (oder wiederverwenden) und die Zeilen
GET /where?q=now HTTP/1.1
Host: www.example.org
senden, gefolgt vom Rest der Anforderungsnachricht.
5.3.2. absolute-form
Bei einer Anfrage an einen Proxy, außer einer CONNECT- oder einer serverweiten OPTIONS-Anfrage (wie unten ausgeführt), muss ein Client den Ziel-URI in absolute-form als Anfrageziel senden.
absolute-form = absolute-URI
Der Proxy wird gebeten, diese Anfrage entweder, wenn möglich, aus einem gültigen Cache zu bedienen oder dieselbe Anfrage im Namen des Clients entweder an den nächsten inbound-Proxy-Server oder direkt an den durch das Anfrageziel angegebenen Ursprungsserver zu stellen. Anforderungen an eine solche "Weiterleitung" von Nachrichten sind in Abschnitt 5.7 definiert.
Ein Beispiel für eine Anfragezeile in absolute-form wäre:
GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
Um den Übergang zur absolute-form für alle Anfragen in einer zukünftigen Version von HTTP zu ermöglichen, muss ein Server die absolute-form in Anfragen akzeptieren, obwohl HTTP/1.1-Clients sie nur in Anfragen an Proxys senden werden.
5.3.3. authority-form
Die authority-form des Anfrageziels wird nur für CONNECT-Anfragen verwendet (Abschnitt 4.3.6 von [RFC7231]).
authority-form = authority
Bei einer CONNECT-Anfrage zum Aufbau eines Tunnels durch einen oder mehrere Proxys muss ein Client als Anfrageziel nur die Authority-Komponente des Ziel-URI senden (ohne jegliche userinfo und deren "@"-Trennzeichen). Zum Beispiel
CONNECT www.example.com:80 HTTP/1.1
5.3.4. asterisk-form
Die asterisk-form des Anfrageziels wird nur für eine serverweite OPTIONS-Anfrage verwendet (Abschnitt 4.3.7 von [RFC7231]).
asterisk-form = "*"
Wenn ein Client OPTIONS für den Server als Ganzes anfragen möchte, im Gegensatz zu einer bestimmten benannten Ressource dieses Servers, muss der Client als Anfrageziel nur "*" (%x2A) senden. Zum Beispiel
OPTIONS * HTTP/1.1
Empfängt ein Proxy eine OPTIONS-Anfrage mit einer absolute-form des Anfrageziels, bei der der URI einen leeren Pfad und keine Query-Komponente hat, dann muss der letzte Proxy in der Anfragekette ein Anfrageziel "*" senden, wenn er die Anfrage an den angegebenen Ursprungsserver weiterleitet.
Beispielsweise würde die Anfrage
OPTIONS http://www.example.org:8001 HTTP/1.1
vom letzten Proxy weitergeleitet als
OPTIONS * HTTP/1.1
Host: www.example.org:8001
nachdem er sich mit Port 8001 des Hosts "www.example.org" verbunden hat.
5.4. Host
Das Header-Feld "Host" in einer Anfrage liefert die Host- und Portinformationen aus dem Ziel-URI und ermöglicht es dem Ursprungsserver, zwischen Ressourcen zu unterscheiden, während er Anfragen für mehrere Hostnamen auf einer einzigen IP-Adresse bedient.
Host = uri-host [ ":" port ] ; Section 2.7.1
Ein Client muss ein Header-Feld Host in allen HTTP/1.1-Anforderungsnachrichten senden. Enthält der Ziel-URI eine Authority-Komponente, dann muss ein Client einen Feldwert für Host senden, der mit dieser Authority-Komponente identisch ist, ohne jegliche userinfo-Subkomponente und deren "@"-Trennzeichen (Abschnitt 2.7.1). Fehlt die Authority-Komponente für den Ziel-URI oder ist sie undefiniert, dann muss ein Client ein Header-Feld Host mit leerem Feldwert senden.
Da der Feldwert von Host eine kritische Information für die Verarbeitung einer Anfrage ist, SOLLTE ein User Agent Host als erstes Header-Feld nach der Anfragezeile erzeugen.
Beispielsweise würde eine GET-Anfrage an den Ursprungsserver für http://www.example.org/pub/WWW/ beginnen mit:
GET /pub/WWW/ HTTP/1.1
Host: www.example.org
Ein Client muss ein Header-Feld Host in einer HTTP/1.1-Anfrage senden, selbst wenn das Anfrageziel in absolute-form vorliegt, da dies ermöglicht, die Host-Informationen durch alte HTTP/1.0-Proxys weiterzuleiten, die möglicherweise Host nicht implementiert haben.
Empfängt ein Proxy eine Anfrage mit einer absolute-form des Anfrageziels, muss der Proxy das empfangene Header-Feld Host (falls vorhanden) ignorieren und es stattdessen durch die Host-Informationen des Anfrageziels ersetzen. Ein Proxy, der eine solche Anfrage weiterleitet, muss einen neuen Feldwert für Host basierend auf dem empfangenen Anfrageziel erzeugen, statt den empfangenen Feldwert von Host weiterzuleiten.
Da das Header-Feld Host als Routing-Mechanismus auf Anwendungsebene fungiert, ist es ein häufiges Ziel für Malware, die einen gemeinsam genutzten Cache vergiften oder eine Anfrage auf einen unbeabsichtigten Server umleiten möchte. Ein Interception Proxy ist besonders anfällig, wenn er sich zum Umleiten von Anfragen an interne Server auf den Feldwert von Host verlässt oder ihn als Cache-Schlüssel in einem gemeinsam genutzten Cache verwendet, ohne zuvor zu überprüfen, dass die abgefangene Verbindung auf eine gültige IP-Adresse für diesen Host abzielt.
Ein Server muss mit dem Statuscode 400 (Bad Request) auf jede HTTP/1.1-Anforderungsnachricht antworten, der ein Header-Feld Host fehlt, sowie auf jede Anforderungsnachricht, die mehr als ein Header-Feld Host oder ein Header-Feld Host mit einem ungültigen Feldwert enthält.
5.5. Effektiver Anfrage-URI
Da das Anfrageziel häufig nur einen Teil des Ziel-URI des User Agent enthält, rekonstruiert ein Server die beabsichtigte Zielressource als "effektiven Anfrage-URI" (effective request URI), um die Anfrage ordnungsgemäß zu bedienen. Diese Rekonstruktion umfasst sowohl die lokale Konfiguration des Servers als auch Informationen, die im Anfrageziel, im Header-Feld Host und im Verbindungskontext mitgeteilt werden.
Für einen User Agent ist der effektive Anfrage-URI der Ziel-URI.
Liegt das Anfrageziel in absolute-form vor, ist der effektive Anfrage-URI derselbe wie das Anfrageziel. Andernfalls wird der effektive Anfrage-URI wie folgt konstruiert:
Stellt die Konfiguration des Servers (oder ein outbound-Gateway) ein festes URI-Schema bereit, wird dieses Schema für den effektiven Anfrage-URI verwendet. Andernfalls, wenn die Anfrage über eine TLS-gesicherte TCP-Verbindung empfangen wird, ist das Schema des effektiven Anfrage-URI "https"; wenn nicht, ist das Schema "http".
Stellt die Konfiguration des Servers (oder ein outbound-Gateway) eine feste URI-Authority-Komponente bereit, wird diese Authority für den effektiven Anfrage-URI verwendet. Wenn nicht, dann ist, wenn das Anfrageziel in authority-form vorliegt, die Authority-Komponente des effektiven Anfrage-URI dieselbe wie das Anfrageziel. Wenn nicht, dann ist, wenn ein Header-Feld Host mit einem nicht leeren Feldwert angegeben wird, die Authority-Komponente dieselbe wie der Feldwert von Host. Andernfalls wird der Authority-Komponente der für den Server konfigurierte Standardname zugewiesen, und wenn die eingehende TCP-Portnummer der Verbindung vom Standardport für das Schema des effektiven Anfrage-URI abweicht, dann werden ein Doppelpunkt (":") und die eingehende Portnummer (in Dezimalform) an die Authority-Komponente angehängt.
Liegt das Anfrageziel in authority-form oder asterisk-form vor, ist die kombinierte Pfad- und Query-Komponente des effektiven Anfrage-URI leer. Andernfalls ist die kombinierte Pfad- und Query-Komponente dieselbe wie das Anfrageziel.
Die Komponenten des effektiven Anfrage-URI können, sobald sie wie oben bestimmt wurden, in absolute-URI-Form kombiniert werden, indem das Schema, "://", die Authority und die kombinierte Pfad- und Query-Komponente konkateniert werden.
Beispiel 1: die folgende über eine ungesicherte TCP-Verbindung empfangene Nachricht
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.example.org:8080
hat den effektiven Anfrage-URI
http://www.example.org:8080/pub/WWW/TheProject.html
Beispiel 2: die folgende über eine TLS-gesicherte TCP-Verbindung empfangene Nachricht
OPTIONS * HTTP/1.1
Host: www.example.org
hat den effektiven Anfrage-URI
https://www.example.org
Empfänger einer HTTP/1.0-Anfrage, der ein Header-Feld Host fehlt, müssen möglicherweise Heuristiken verwenden (z. B. die Prüfung des URI-Pfads auf etwas, das für einen bestimmten Host einzigartig ist), um die Authority-Komponente des effektiven Anfrage-URI zu erraten.
Sobald der effektive Anfrage-URI konstruiert wurde, muss ein Ursprungsserver entscheiden, ob er für diesen URI über die Verbindung, in der die Anfrage empfangen wurde, einen Dienst anbietet oder nicht. Beispielsweise könnte die Anfrage absichtlich oder versehentlich fehlgeleitet worden sein, sodass sich die Informationen innerhalb eines empfangenen Anfrageziels oder Header-Felds Host von dem Host oder Port unterscheiden, über den die Verbindung hergestellt wurde. Stammt die Verbindung von einem vertrauenswürdigen Gateway, kann diese Inkonsistenz erwartet werden; andernfalls könnte sie den Versuch anzeigen, Sicherheitsfilter zu umgehen, den Server dazu zu bringen, nicht-öffentliche Inhalte auszuliefern, oder einen Cache zu vergiften. Siehe Abschnitt 9 zu Sicherheitserwägungen bezüglich des Nachrichten-Routings.
5.6. Zuordnung einer Antwort zu einer Anfrage
HTTP enthält keinen Anfragebezeichner, um eine bestimmte Anforderungsnachricht ihrer entsprechenden einen oder mehreren Antwortnachrichten zuzuordnen. Daher verlässt es sich darauf, dass die Reihenfolge des Eintreffens der Antworten genau der Reihenfolge entspricht, in der Anfragen auf derselben Verbindung gestellt werden. Mehr als eine Antwortnachricht pro Anfrage tritt nur auf, wenn eine oder mehrere informative Antworten (1xx, siehe Abschnitt 6.2 von [RFC7231]) einer endgültigen Antwort auf dieselbe Anfrage vorausgehen.
Ein Client, der mehr als eine offene Anfrage auf einer Verbindung hat, muss eine Liste der offenen Anfragen in der Reihenfolge ihres Sendens führen und muss jede auf dieser Verbindung empfangene Antwortnachricht der am höchsten geordneten Anfrage zuordnen, die noch keine endgültige (nicht-1xx) Antwort erhalten hat.
5.7. Nachrichtenweiterleitung
Wie in Abschnitt 2.3 beschrieben, können Vermittler eine Vielzahl von Rollen bei der Verarbeitung von HTTP-Anfragen und -Antworten übernehmen. Einige Vermittler werden zur Verbesserung von Leistung oder Verfügbarkeit eingesetzt. Andere werden zur Zugangskontrolle oder zum Filtern von Inhalten verwendet. Da ein HTTP-Stream Ähnlichkeiten mit einer Pipe-and-Filter-Architektur hat, gibt es keine inhärenten Grenzen dafür, in welchem Umfang ein Vermittler den Stream in beide Richtungen erweitern (oder stören) kann.
Ein Vermittler, der nicht als Tunnel agiert, MUSS das Header-Feld Connection implementieren, wie in Abschnitt 6.1 festgelegt, und Felder von der Weiterleitung ausschließen, die nur für die eingehende Verbindung bestimmt sind.
Ein Vermittler darf eine Nachricht NICHT an sich selbst weiterleiten, es sei denn, er ist vor einer unendlichen Anforderungsschleife geschützt. Im Allgemeinen sollte ein Vermittler seine eigenen Servernamen erkennen, einschließlich etwaiger Aliasnamen, lokaler Varianten oder wörtlicher IP-Adressen, und auf solche Anfragen direkt antworten.
5.7.1. Via
Das Header-Feld "Via" zeigt das Vorhandensein von Zwischenprotokollen und Empfängern zwischen dem User Agent und dem Server (bei Anfragen) oder zwischen dem Ursprungsserver und dem Client (bei Antworten) an, ähnlich dem Header-Feld "Received" in E-Mails (Abschnitt 3.6.7 von [RFC5322]). Via kann zum Verfolgen von Nachrichtenweiterleitungen, zum Vermeiden von Anforderungsschleifen und zum Identifizieren der Protokollfähigkeiten von Absendern entlang der Anfrage/Antwort-Kette verwendet werden.
Via = 1#( received-protocol RWS received-by [ RWS comment ] )
received-protocol = [ protocol-name "/" ] protocol-version
; see Section 6.7
received-by = ( uri-host [ ":" port ] ) / pseudonym
pseudonym = token
Mehrere Feldwerte von Via repräsentieren jeden Proxy oder Gateway, der die Nachricht weitergeleitet hat. Jeder Vermittler hängt seine eigenen Informationen darüber an, wie die Nachricht empfangen wurde, sodass das Endergebnis gemäß der Reihenfolge der weiterleitenden Empfänger geordnet ist.
Ein Proxy MUSS ein geeignetes Header-Feld Via, wie unten beschrieben, in jeder Nachricht senden, die er weiterleitet. Ein HTTP-zu-HTTP-Gateway MUSS ein geeignetes Header-Feld Via in jeder inbound-Anforderungsnachricht senden und KANN ein Header-Feld Via in weitergeleiteten Antwortnachrichten senden.
Für jeden Vermittler zeigt received-protocol das Protokoll und die Protokollversion an, die der vorgelagerte Absender der Nachricht verwendet hat. Daher zeichnet der Feldwert von Via die angegebenen Protokollfähigkeiten der Anfrage/Antwort-Kette auf, sodass sie für downstream-Empfänger sichtbar bleiben; dies kann nützlich sein, um zu bestimmen, welche abwärtsinkompatiblen Funktionen in der Antwort oder in einer späteren Anfrage sicher zu verwenden sind, wie in Abschnitt 2.6 beschrieben. Der Kürze halber wird protocol-name weggelassen, wenn das empfangene Protokoll HTTP ist.
Der Teil received-by des Feldwerts ist normalerweise der Host und die optionale Portnummer eines Empfängerservers oder -clients, der die Nachricht anschließend weitergeleitet hat. Wird der echte Host jedoch als sensible Information betrachtet, KANN ein Absender ihn durch ein Pseudonym ersetzen. Ist kein Port angegeben, KANN ein Empfänger dies so interpretieren, dass die Nachricht über den Standard-TCP-Port (falls vorhanden) für das received-protocol empfangen wurde.
Ein Absender KANN Kommentare im Header-Feld Via erzeugen, um die Software jedes Empfängers zu identifizieren, analog zu den Header-Feldern User-Agent und Server. Alle Kommentare im Feld Via sind jedoch optional, und ein Empfänger KANN sie vor dem Weiterleiten der Nachricht entfernen.
Beispielsweise könnte eine Anforderungsnachricht von einem HTTP/1.0-User-Agent an einen internen Proxy mit dem Codenamen "fred" gesendet werden, der HTTP/1.1 verwendet, um die Anfrage an einen öffentlichen Proxy unter p.example.net weiterzuleiten, der die Anfrage abschließt, indem er sie an den Ursprungsserver unter www.example.com weiterleitet. Die von www.example.com empfangene Anfrage hätte dann das folgende Header-Feld Via:
Via: 1.0 fred, 1.1 p.example.net
Ein Vermittler, der als Portal durch eine Netzwerk-Firewall verwendet wird, SOLLTE NICHT die Namen und Ports von Hosts innerhalb des Firewall-Bereichs weiterleiten, es sei denn, er ist ausdrücklich dafür aktiviert. Ist er nicht aktiviert, SOLLTE ein solcher Vermittler jeden empfangenen received-by-Host eines Hosts hinter der Firewall durch ein geeignetes Pseudonym für diesen Host ersetzen.
Ein Vermittler KANN eine geordnete Teilfolge von Via-Header-Feld-Einträgen zu einem einzigen solchen Eintrag zusammenfassen, wenn die Einträge identische received-protocol-Werte haben. Zum Beispiel
Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
könnte zusammengefasst werden zu
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
Ein Absender SOLLTE NICHT mehrere Einträge zusammenfassen, es sei denn, sie stehen alle unter derselben organisatorischen Kontrolle und die Hosts wurden bereits durch Pseudonyme ersetzt. Ein Absender darf Einträge mit unterschiedlichen received-protocol-Werten NICHT zusammenfassen.
5.7.2. Transformationen
Einige Vermittler enthalten Funktionen zum Transformieren von Nachrichten und deren Payloads. Ein Proxy könnte beispielsweise zwischen Bildformaten konvertieren, um Cache-Speicherplatz zu sparen oder die Verkehrsmenge auf einer langsamen Verbindung zu reduzieren. Betriebsprobleme können jedoch auftreten, wenn diese Transformationen auf Payloads angewendet werden, die für kritische Anwendungen bestimmt sind, etwa medizinische Bildgebung oder wissenschaftliche Datenanalyse, insbesondere wenn Integritätsprüfungen oder digitale Signaturen verwendet werden, um sicherzustellen, dass der empfangene Payload mit dem Original identisch ist.
Ein HTTP-zu-HTTP-Proxy wird als "transforming proxy" bezeichnet, wenn er darauf ausgelegt oder konfiguriert ist, Nachrichten in semantisch bedeutsamer Weise zu verändern (d. h. Änderungen, die über die durch die normale HTTP-Verarbeitung erforderlichen hinausgehen und die Nachricht in einer Weise ändern, die für den ursprünglichen Absender von Bedeutung oder für downstream-Empfänger potenziell von Bedeutung wäre). Beispielsweise könnte ein transforming proxy als gemeinsam genutzter Annotationsserver (der Antworten ändert, um Verweise auf eine lokale Annotationsdatenbank aufzunehmen), als Malware-Filter, als Format-Transcoder oder als Datenschutzfilter agieren. Solche Transformationen werden als von demjenigen Client (oder der Client-Organisation) gewünscht vorausgesetzt, der den Proxy ausgewählt hat.
Empfängt ein Proxy ein Anfrageziel mit einem Hostnamen, der kein vollständig qualifizierter Domänenname ist, KANN er seinen eigenen Domänennamen an den empfangenen Hostnamen anhängen, wenn er die Anfrage weiterleitet. Ein Proxy darf den Hostnamen NICHT ändern, wenn das Anfrageziel einen vollständig qualifizierten Domänennamen enthält.
Ein Proxy darf die Teile "absolute-path" und "query" des empfangenen Anfrageziels NICHT ändern, wenn er es an den nächsten inbound-Server weiterleitet, außer wie oben erwähnt, um einen leeren Pfad durch "/" oder "*" zu ersetzen.
Ein Proxy KANN den Nachrichtenkörper durch Anwenden oder Entfernen einer Transferkodierung ändern (Abschnitt 4).
Ein Proxy darf den Payload (Abschnitt 3.3 von [RFC7231]) einer Nachricht, die eine Cache-Control-Direktive no-transform enthält, NICHT transformieren (Abschnitt 5.2 von [RFC7234]).
Ein Proxy KANN den Payload einer Nachricht transformieren, die keine Cache-Control-Direktive no-transform enthält. Ein Proxy, der einen Payload transformiert, MUSS ein Header-Feld Warning mit dem warn-code 214 ("Transformation Applied") hinzufügen, falls nicht bereits eines in der Nachricht vorhanden ist (siehe Abschnitt 5.5 von [RFC7234]). Ein Proxy, der den Payload einer 200-Antwort (OK) transformiert, kann downstream-Empfänger weiter darüber informieren, dass eine Transformation angewendet wurde, indem er den Antwortstatuscode auf 203 (Non-Authoritative Information) ändert (Abschnitt 6.3.4 von [RFC7231]).
Ein Proxy SOLLTE NICHT Header-Felder ändern, die Informationen über die Endpunkte der Kommunikationskette, den Ressourcenzustand oder die ausgewählte Repräsentation (außer dem Payload) liefern, es sei denn, die Definition des Felds erlaubt eine solche Änderung ausdrücklich oder die Änderung wird für Datenschutz oder Sicherheit als notwendig erachtet.