7. Routing von HTTP-Nachrichten (Routing HTTP Messages)

Das Routing von HTTP-Anfragenachrichten wird von jedem Client basierend auf der Zielressource, der Proxy-Konfiguration des Clients und der Herstellung oder Wiederverwendung einer eingehenden Verbindung bestimmt. Das entsprechende Antwort-Routing folgt derselben Verbindungskette zurück zum Client.

7.1. Bestimmung der Zielressource (Determining the Target Resource)

Obwohl HTTP in einer Vielzahl von Anwendungen verwendet wird, verlassen sich die meisten Clients auf denselben Ressourcenidentifikationsmechanismus und dieselben Konfigurationstechniken wie allgemeine Webbrowser. Selbst wenn Kommunikationsoptionen fest in der Konfiguration eines Clients codiert sind, können wir ihre kombinierte Wirkung als URI-Referenz betrachten (Section 4.1).

Eine URI-Referenz wird in ihre absolute Form aufgelöst, um die「Ziel-URI」(target URI) zu erhalten. Die Ziel-URI schließt die Fragment-Komponente der Referenz aus, falls vorhanden, da Fragment-Identifikatoren für die clientseitige Verarbeitung reserviert sind ([URI], Section 3.5).

Um eine Aktion auf einer「Zielressource」(target resource) auszuführen, sendet der Client eine Anfragenachricht, die genügend Komponenten seiner geparsten Ziel-URI enthält, um den Empfängern die Identifikation derselben Ressource zu ermöglichen. Aus historischen Gründen werden die geparsten Ziel-URI-Komponenten, die zusammen als「Anfrageziel」(request target) bezeichnet werden, innerhalb der Nachrichtenkontrolldaten und des Host-Header-Feldes (Section 7.2) gesendet.

Es gibt zwei ungewöhnliche Fälle, bei denen die Anfragezielkomponenten in einer methodenspezifischen Form vorliegen:

• Für CONNECT (Section 9.3.6) ist das Anfrageziel der Hostname und die Portnummer des Tunnelziels, getrennt durch einen Doppelpunkt.

• Für OPTIONS (Section 9.3.7) kann das Anfrageziel ein einzelnes Sternchen ("*") sein.

Siehe die jeweiligen Methodendefinitionen für Details. Diese Formen DÜRFEN NICHT (MUST NOT) mit anderen Methoden verwendet werden.

Nach Erhalt einer Client-Anfrage rekonstruiert ein Server die Ziel-URI aus den empfangenen Komponenten gemäß seiner lokalen Konfiguration und dem eingehenden Verbindungskontext. Diese Rekonstruktion ist spezifisch für jede Hauptprotokollversion. Beispielsweise definiert Section 3.3 von [HTTP/1.1], wie ein Server die Ziel-URI einer HTTP/1.1-Anfrage bestimmt.

Hinweis: Frühere Spezifikationen definierten die rekombinierte Ziel-URI als ein eigenständiges Konzept, die「effektive Anfrage-URI」(effective request URI).

7.2. Host und :authority

Das「Host」-Header-Feld in einer Anfrage liefert die Host- und Port-Informationen aus der Ziel-URI und ermöglicht es dem Ursprungsserver, zwischen Ressourcen zu unterscheiden, während er Anfragen für mehrere Hostnamen bedient.

In HTTP/2 [HTTP/2] und HTTP/3 [HTTP/3] wird das Host-Header-Feld in einigen Fällen durch das「:authority」-Pseudo-Header-Feld der Kontrolldaten einer Anfrage ersetzt.

Host = uri-host [ ":" port ] ; Section 4

Die Authority-Informationen der Ziel-URI sind für die Bearbeitung einer Anfrage entscheidend. Ein User-Agent MUSS (MUST) ein Host-Header-Feld in einer Anfrage generieren, es sei denn, er sendet diese Informationen als「:authority」-Pseudo-Header-Feld. Ein User-Agent, der Host sendet, SOLLTE (SHOULD) es als erstes Feld im Header-Abschnitt einer Anfrage senden.

Zum Beispiel würde eine GET-Anfrage an den Ursprungsserver für http://www.example.org/pub/WWW/ wie folgt beginnen:

GET /pub/WWW/ HTTP/1.1
Host: www.example.org

Da die Host- und Port-Informationen als Anwendungsebenen-Routing-Mechanismus fungieren, sind sie ein häufiges Ziel für Malware, die versucht, einen gemeinsam genutzten Cache zu vergiften oder eine Anfrage an einen unbeabsichtigten Server umzuleiten. Ein Interception-Proxy ist besonders anfällig, wenn er sich auf die Host- und Port-Informationen verlässt, um Anfragen an interne Server umzuleiten oder als Cache-Schlüssel in einem gemeinsam genutzten Cache zu verwenden, ohne vorher zu überprüfen, dass die abgefangene Verbindung auf eine gültige IP-Adresse für diesen Host abzielt.

7.3. Routing eingehender Anfragen (Routing Inbound Requests)

Sobald die Ziel-URI und ihr Ursprung bestimmt sind, entscheidet ein Client, ob eine Netzwerkanfrage erforderlich ist, um die gewünschte Semantik zu erreichen, und wenn ja, wohin diese Anfrage gerichtet werden soll.

7.3.1. An einen Cache (To a Cache)

Wenn der Client einen Cache [CACHING] hat und die Anfrage durch ihn erfüllt werden kann, wird die Anfrage normalerweise zuerst dorthin geleitet.

7.3.2. An einen Proxy (To a Proxy)

Wenn die Anfrage nicht durch einen Cache erfüllt wird, überprüft ein typischer Client seine Konfiguration, um festzustellen, ob ein Proxy verwendet werden soll, um die Anfrage zu erfüllen. Die Proxy-Konfiguration ist implementierungsabhängig, basiert aber oft auf URI-Präfix-Matching, selektivem Authority-Matching oder beidem, und der Proxy selbst wird normalerweise durch eine「http」- oder「https」-URI identifiziert.

Wenn ein「http」- oder「https」-Proxy anwendbar ist, verbindet sich der Client eingehend, indem er eine Verbindung zu diesem Proxy herstellt (oder wiederverwendet) und ihm dann eine HTTP-Anfragenachricht sendet, die ein Anfrageziel enthält, das der Ziel-URI des Clients entspricht.

7.3.3. Zum Ursprung (To the Origin)

Wenn kein Proxy anwendbar ist, ruft ein typischer Client eine Handler-Routine (spezifisch für das Schema der Ziel-URI) auf, um Zugriff auf die identifizierte Ressource zu erhalten. Wie dies erreicht wird, hängt vom Ziel-URI-Schema ab und wird durch seine zugehörige Spezifikation definiert.

Section 4.3.2 definiert, wie Zugriff auf eine「http」-Ressource erlangt wird, indem eine eingehende Verbindung zum identifizierten Ursprungsserver hergestellt (oder wiederverwendet) wird und ihm dann eine HTTP-Anfragenachricht gesendet wird, die ein Anfrageziel enthält, das der Ziel-URI des Clients entspricht.

Section 4.3.3 definiert, wie Zugriff auf eine「https」-Ressource erlangt wird, indem eine eingehende gesicherte Verbindung zu einem Ursprungsserver hergestellt (oder wiederverwendet) wird, der für den identifizierten Ursprung autoritativ ist, und ihm dann eine HTTP-Anfragenachricht gesendet wird, die ein Anfrageziel enthält, das der Ziel-URI des Clients entspricht.

7.4. Ablehnung fehlgeleiteter Anfragen (Rejecting Misdirected Requests)

Sobald eine Anfrage von einem Server empfangen und ausreichend geparst wurde, um seine Ziel-URI zu bestimmen, entscheidet der Server, ob er die Anfrage selbst verarbeitet, die Anfrage an einen anderen Server weiterleitet, den Client an eine andere Ressource umleitet, mit einem Fehler antwortet oder die Verbindung abbricht. Diese Entscheidung kann durch alles über die Anfrage oder den Verbindungskontext beeinflusst werden, richtet sich aber speziell darauf, ob der Server so konfiguriert wurde, dass er Anfragen für diese Ziel-URI verarbeitet, und ob der Verbindungskontext für diese Anfrage angemessen ist.

Beispielsweise könnte eine Anfrage absichtlich oder versehentlich fehlgeleitet worden sein, sodass die Informationen in einem empfangenen Host-Header-Feld vom Host oder Port der Verbindung abweichen. Wenn die Verbindung von einem vertrauenswürdigen Gateway stammt, kann eine solche Inkonsistenz erwartet werden; andernfalls könnte sie einen Versuch anzeigen, Sicherheitsfilter zu umgehen, den Server zu täuschen, nicht-öffentliche Inhalte zu liefern, oder einen Cache zu vergiften. Siehe Section 17 für Sicherheitsüberlegungen bezüglich des Nachrichtenroutings.

Sofern die Verbindung nicht von einem vertrauenswürdigen Gateway stammt, MUSS (MUST) ein Ursprungsserver eine Anfrage ablehnen, wenn schema-spezifische Anforderungen für die Ziel-URI nicht erfüllt sind. Insbesondere MUSS (MUST) eine Anfrage für eine「https」-Ressource abgelehnt werden, es sei denn, sie wurde über eine Verbindung empfangen, die über ein für den Ursprung dieser Ziel-URI gültiges Zertifikat gesichert wurde, wie in Section 4.2.2 definiert.

Der 421 (Misdirected Request) Statuscode in einer Antwort zeigt an, dass der Ursprungsserver die Anfrage abgelehnt hat, weil sie fehlgeleitet zu sein scheint (Section 15.5.20).

7.5. Antwort-Korrelation (Response Correlation)

Eine Verbindung kann für mehrere Anfrage/Antwort-Austausche verwendet werden. Der Mechanismus, der zur Korrelation zwischen Anfrage- und Antwortnachrichten verwendet wird, ist versionsabhängig; einige Versionen von HTTP verwenden implizite Ordnung von Nachrichten, während andere einen expliziten Identifikator verwenden.

Alle Antworten können unabhängig vom Statuscode (einschließlich Zwischenantworten) zu jedem Zeitpunkt nach Empfang einer Anfrage gesendet werden, auch wenn die Anfrage noch nicht vollständig ist. Eine Antwort kann abgeschlossen werden, bevor die entsprechende Anfrage abgeschlossen ist (Section 6.1). Ebenso wird von Clients nicht erwartet, dass sie eine bestimmte Zeit auf eine Antwort warten. Clients (einschließlich Intermediäre) können eine Anfrage aufgeben, wenn die Antwort nicht innerhalb eines angemessenen Zeitraums empfangen wird.

Ein Client, der eine Antwort erhält, während er die zugehörige Anfrage noch sendet, SOLLTE (SHOULD) diese Anfrage weiterhin senden, es sei denn, er erhält eine explizite Anweisung zum Gegenteil (siehe z.B. Section 9.5 von [HTTP/1.1] und Section 6.4 von [HTTP/2]).

7.6. Nachrichtenweiterleit

Wie in Section 3.7 beschrieben, können Intermediäre verschiedene Rollen bei der Verarbeitung von HTTP-Anfragen und -Antworten spielen. Einige Intermediäre werden verwendet, um Leistung oder Verfügbarkeit zu verbessern. Andere werden für Zugriffskontrolle oder zum Filtern von Inhalten verwendet. Da ein HTTP-Stream Eigenschaften ähnlich einer Pipe-and-Filter-Architektur hat, gibt es keine inhärenten Grenzen für das Ausmaß, in dem ein Intermediär entweder die eine oder die andere Richtung des Streams verbessern (oder stören) kann.

Von Intermediären wird erwartet, dass sie Nachrichten weiterleiten, auch wenn Protokollelemente nicht erkannt werden (z.B. neue Methoden, Statuscodes oder Feldnamen), da dies die Erweiterbarkeit für nachgelagerte Empfänger bewahrt.

Ein Intermediär, der nicht als Tunnel fungiert, MUSS (MUST) das Connection-Header-Feld implementieren, wie in Section 7.6.1 spezifiziert, und Felder vom Weiterleiten ausschließen, die nur für die eingehende Verbindung bestimmt sind.

Ein Intermediär DARF NICHT (MUST NOT) eine Nachricht an sich selbst weiterleiten, es sei denn, er ist vor einer unendlichen Anfrageschleife geschützt. Im Allgemeinen sollte ein Intermediär seine eigenen Servernamen erkennen, einschließlich aller Aliase, lokaler Variationen oder Literal-IP-Adressen, und direkt auf solche Anfragen antworten.

Eine HTTP-Nachricht kann als Stream für inkrementelle Verarbeitung oder Weiterleitung nachgelagert analysiert werden. Sender und Empfänger können sich jedoch nicht auf die inkrementelle Zustellung von Teilnachrichten verlassen, da einige Implementierungen die Nachrichtenweiterleitung aus Gründen der Netzwerkeffizienz, Sicherheitsprüfungen oder Inhaltstransformationen puffern oder verzögern werden.

7.6.1. Connection

Das「Connection」-Header-Feld ermöglicht es dem Sender, gewünschte Steuerungsoptionen für die aktuelle Verbindung aufzulisten.

Connection        = #connection-option
connection-option = token

Verbindungsoptionen sind nicht case-sensitiv.

Wenn ein Feld außer Connection verwendet wird, um Steuerungsinformationen für oder über die aktuelle Verbindung bereitzustellen, MUSS (MUST) der Sender den entsprechenden Feldnamen im Connection-Header-Feld auflisten. Beachten Sie, dass einige Versionen von HTTP die Verwendung von Feldern für solche Informationen verbieten und daher das Connection-Feld nicht erlauben.

Intermediäre MÜSSEN (MUST) ein empfangenes Connection-Header-Feld parsen, bevor eine Nachricht weitergeleitet wird, und für jede connection-option in diesem Feld alle Header- oder Trailer-Feld(er) aus der Nachricht mit demselben Namen wie die connection-option entfernen und dann das Connection-Header-Feld selbst entfernen (oder es durch die eigenen Steuerungsoptionen des Intermediärs für die weitergeleitete Nachricht ersetzen).

Daher bietet das Connection-Header-Feld eine deklarative Möglichkeit, Felder zu unterscheiden, die nur für den unmittelbaren Empfänger bestimmt sind (「hop-by-hop」), von solchen Feldern, die für alle Empfänger in der Kette bestimmt sind (「end-to-end」), wodurch die Nachricht selbstbeschreibend wird und zukünftige verbindungsspezifische Erweiterungen bereitgestellt werden können, ohne befürchten zu müssen, dass sie von älteren Intermediären blind weitergeleitet werden.

Darüber hinaus SOLLTEN (SHOULD) Intermediäre Felder entfernen oder ersetzen, von denen bekannt ist, dass sie vor der Weiterleitung entfernt werden müssen, unabhängig davon, ob sie als connection-option erscheinen, nachdem die Semantik dieser Felder angewendet wurde. Dies umfasst unter anderem:

• Proxy-Connection (Appendix C.2.2 von [HTTP/1.1])
• Keep-Alive (Section 19.7.1 von [RFC2068])
• TE (Section 10.1.4)
• Transfer-Encoding (Section 6.1 von [HTTP/1.1])
• Upgrade (Section 7.8)

Ein Sender DARF NICHT (MUST NOT) eine Verbindungsoption senden, die einem Feld entspricht, das für alle Empfänger des Inhalts bestimmt ist. Beispielsweise ist Cache-Control niemals als Verbindungsoption geeignet (Section 5.2 von [CACHING]).

Verbindungsoptionen entsprechen nicht immer einem in der Nachricht vorhandenen Feld, da ein verbindungsspezifisches Feld möglicherweise nicht benötigt wird, wenn keine Parameter mit einer Verbindungsoption verknüpft sind. Im Gegensatz dazu deutet ein verbindungsspezifisches Feld, das ohne entsprechende Verbindungsoption empfangen wird, normalerweise darauf hin, dass das Feld von einem Intermediär unsachgemäß weitergeleitet wurde und vom Empfänger ignoriert werden sollte.

Bei der Definition einer neuen Verbindungsoption, die keinem Feld entspricht, sollten Spezifikationsautoren den entsprechenden Feldnamen trotzdem reservieren, um spätere Kollisionen zu vermeiden. Solche reservierten Feldnamen werden im「Hypertext Transfer Protocol (HTTP) Field Name Registry」(Section 16.3.1) registriert.

7.6.2. Max-Forwards

Das「Max-Forwards」-Header-Feld bietet einen Mechanismus mit den TRACE (Section 9.3.8) und OPTIONS (Section 9.3.7) Anfragemethoden, um die Anzahl der Male zu begrenzen, die die Anfrage von Proxies weitergeleitet wird. Dies kann nützlich sein, wenn der Client versucht, eine Anfrage zu verfolgen, die anscheinend mitten in der Kette fehlschlägt oder eine Schleife bildet.

Max-Forwards = 1*DIGIT

Der Max-Forwards-Wert ist eine Dezimalzahl, die die verbleibende Anzahl von Malen angibt, die diese Anfragenachricht weitergeleitet werden kann.

Jeder Intermediär, der eine TRACE- oder OPTIONS-Anfrage mit einem Max-Forwards-Header-Feld empfängt, MUSS (MUST) seinen Wert überprüfen und aktualisieren, bevor er die Anfrage weiterleitet. Wenn der empfangene Wert Null (0) ist, DARF (MUST NOT) der Intermediär die Anfrage NICHT weiterleiten; stattdessen MUSS (MUST) der Intermediär als endgültiger Empfänger antworten. Wenn der empfangene Max-Forwards-Wert größer als Null ist, MUSS (MUST) der Intermediär ein aktualisiertes Max-Forwards-Feld in der weitergeleiteten Nachricht mit einem Feldwert generieren, der der kleinere von a) dem empfangenen Wert um eins (1) verringert oder b) dem vom Empfänger maximal unterstützten Wert für Max-Forwards ist.

Ein Empfänger KANN (MAY) ein Max-Forwards-Header-Feld ignorieren, das mit anderen Anfragemethoden empfangen wird.

7.6.3. Via

Das「Via」-Header-Feld 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「Received」-Header-Feld in E-Mails (Section 3.6.7 von [RFC5322]). Via kann verwendet werden, um Nachrichtenweiterleitungen zu verfolgen, Anfrageschleifen zu vermeiden und die Protokollfähigkeiten von Sendern entlang der Anfrage/Antwort-Kette zu identifizieren.

Via = #( received-protocol RWS received-by [ RWS comment ] )

received-protocol = [ protocol-name "/" ] protocol-version
                  ; siehe Section 7.8
received-by       = pseudonym [ ":" port ]
pseudonym         = token

Jedes Mitglied des Via-Feldwerts repräsentiert einen Proxy oder Gateway, der die Nachricht weitergeleitet hat. Jeder Intermediär fügt seine eigenen Informationen darüber hinzu, wie die Nachricht empfangen wurde, sodass das Endergebnis gemäß der Sequenz der weiterleitenden Empfänger geordnet ist.

Ein Proxy MUSS (MUST) ein geeignetes Via-Header-Feld, wie unten beschrieben, in jeder Nachricht senden, die er weiterleitet. Ein HTTP-zu-HTTP-Gateway MUSS (MUST) ein geeignetes Via-Header-Feld in jeder eingehenden Anfragenachricht senden und KANN (MAY) ein Via-Header-Feld in weitergeleiteten Antwortnachrichten senden.

Für jeden Intermediär zeigt das received-protocol das Protokoll und die Protokollversion an, die vom Upstream-Sender der Nachricht verwendet wurden. Daher zeichnet der Via-Feldwert die angekündigten Protokollfähigkeiten der Anfrage/Antwort-Kette auf, sodass sie für nachgelagerte Empfänger sichtbar bleiben; dies kann nützlich sein, um zu bestimmen, welche rückwärtsinkompatiblen Funktionen in der Antwort oder in einer späteren Anfrage sicher verwendet werden können, wie in Section 2.5 beschrieben. Aus Gründen der Kürze wird der protocol-name weggelassen, wenn das empfangene Protokoll HTTP ist.

Der received-by-Teil ist normalerweise der Host und die optionale Portnummer eines Empfängerservers oder -clients, der die Nachricht anschließend weitergeleitet hat. Wenn der echte Host jedoch als sensible Information betrachtet wird, KANN (MAY) ein Sender ihn durch ein Pseudonym ersetzen. Wenn kein Port angegeben ist, KANN (MAY) ein Empfänger dies so interpretieren, dass es auf dem Standard-Port, falls vorhanden, für das received-protocol empfangen wurde.

Ein Sender KANN (MAY) Kommentare generieren, um die Software jedes Empfängers zu identifizieren, analog zu den User-Agent- und Server-Header-Feldern. Kommentare in Via sind jedoch optional, und ein Empfänger KANN (MAY) sie vor der Weiterleitung der Nachricht entfernen.

Zum Beispiel könnte eine Anfragenachricht 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 bei p.example.net weiterzuleiten, der die Anfrage vervollständigt, indem er sie an den Ursprungsserver bei www.example.com weiterleitet. Die von www.example.com empfangene Anfrage hätte dann das folgende Via-Header-Feld:

Via: 1.0 fred, 1.1 p.example.net

Ein Intermediär, der als Portal durch eine Netzwerk-Firewall verwendet wird, SOLLTE NICHT (SHOULD NOT) die Namen und Ports von Hosts innerhalb der Firewall-Region weiterleiten, es sei denn, er ist ausdrücklich dazu berechtigt. Wenn nicht berechtigt, SOLLTE (SHOULD) ein solcher Intermediär jeden received-by-Host eines Hosts hinter der Firewall durch ein geeignetes Pseudonym für diesen Host ersetzen.

Ein Intermediär KANN (MAY) eine geordnete Teilsequenz von Via-Header-Feld-Listenmitgliedern zu einem einzigen Mitglied kombinieren, 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 auf

Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

reduziert werden.

Ein Sender SOLLTE NICHT (SHOULD NOT) mehrere Listenmitglieder kombinieren, es sei denn, sie stehen alle unter derselben organisatorischen Kontrolle und die Hosts wurden bereits durch Pseudonyme ersetzt. Ein Sender DARF NICHT (MUST NOT) Mitglieder kombinieren, die unterschiedliche received-protocol-Werte haben.

7.7. Nachrichtentransformationen (Message Transformations)

Einige Intermediäre enthalten Funktionen zum Transformieren von Nachrichten und deren Inhalt. Ein Proxy könnte beispielsweise zwischen Bildformaten konvertieren, um Cache-Speicherplatz zu sparen oder die Menge des Verkehrs auf einer langsamen Verbindung zu reduzieren. Betriebsprobleme können jedoch auftreten, wenn diese Transformationen auf Inhalte angewendet werden, die für kritische Anwendungen wie medizinische Bildgebung oder wissenschaftliche Datenanalyse bestimmt sind, insbesondere wenn Integritätsprüfungen oder digitale Signaturen verwendet werden, um sicherzustellen, dass der empfangene Inhalt mit dem Original identisch ist.

Ein HTTP-zu-HTTP-Proxy wird als「transformierender Proxy」(transforming proxy) bezeichnet, wenn er entworfen oder konfiguriert ist, um Nachrichten auf semantisch bedeutsame Weise zu modifizieren (d.h. Modifikationen, die über die durch normale HTTP-Verarbeitung erforderlichen hinausgehen, die die Nachricht auf eine Weise ändern, die für den ursprünglichen Sender bedeutend oder für nachgelagerte Empfänger potenziell bedeutend wäre). Beispielsweise könnte ein transformierender Proxy als gemeinsamer Annotationsserver fungieren (Antworten modifizieren, um Verweise auf eine lokale Annotationsdatenbank einzuschließen), ein Malware-Filter, ein Format-Transcoder oder ein Datenschutzfilter. Solche Transformationen werden als vom Client (oder der Client-Organisation), der den Proxy gewählt hat, gewünscht angenommen.

Wenn ein Proxy eine Ziel-URI mit einem Hostnamen empfängt, der kein vollständig qualifizierter Domänenname ist, KANN (MAY) er seine eigene Domain zum empfangenen Hostnamen hinzufügen, wenn er die Anfrage weiterleitet. Ein Proxy DARF NICHT (MUST NOT) den Hostnamen ändern, wenn die Ziel-URI einen vollständig qualifizierten Domainnamen enthält.

Ein Proxy DARF NICHT (MUST NOT) die「absolute-path」- und「query」-Teile der empfangenen Ziel-URI ändern, wenn er sie an den nächsten eingehenden Server weiterleitet, außer wie es durch dieses Weiterleitungsprotokoll erforderlich ist. Beispielsweise wird ein Proxy, der eine Anfrage über HTTP/1.1 an einen Ursprungsserver weiterleitet, einen leeren Pfad durch「/」(Section 3.2.1 von [HTTP/1.1]) oder「*」(Section 3.2.4 von [HTTP/1.1]) ersetzen, abhängig von der Anfragemethode.

Ein Proxy DARF NICHT (MUST NOT) den Inhalt (Section 6.4) einer Antwortnachricht transformieren, die eine no-transform-Cache-Direktive enthält (Section 5.2.2.6 von [CACHING]). Beachten Sie, dass dies nicht für Nachrichtentransformationen gilt, die den Inhalt nicht ändern, wie das Hinzufügen oder Entfernen von Transfer-Codierungen (Section 7 von [HTTP/1.1]).

Ein Proxy KANN (MAY) den Inhalt einer Nachricht transformieren, die keine no-transform-Cache-Direktive enthält. Ein Proxy, der den Inhalt einer 200 (OK)-Antwort transformiert, kann nachgelagerte Empfänger informieren, dass eine Transformation angewendet wurde, indem er den Antwortstatuscode auf 203 (Non-Authoritative Information) (Section 15.3.4) ändert.

Ein Proxy SOLLTE NICHT (SHOULD NOT) Header-Felder modifizieren, die Informationen über die Endpunkte der Kommunikationskette, den Ressourcenzustand oder die ausgewählte Repräsentation (außer dem Inhalt) bereitstellen, es sei denn, die Definition des Feldes erlaubt eine solche Modifikation ausdrücklich oder die Modifikation wird aus Datenschutz- oder Sicherheitsgründen als notwendig erachtet.

7.8. Upgrade

Das「Upgrade」-Header-Feld soll einen einfachen Mechanismus für den Übergang von HTTP/1.1 zu einem anderen Protokoll auf derselben Verbindung bieten.

Ein Client KANN (MAY) eine Liste von Protokollnamen im Upgrade-Header-Feld einer Anfrage senden, um den Server einzuladen, vor dem Senden der endgültigen Antwort zu einem oder mehreren der benannten Protokolle zu wechseln, in absteigender Reihenfolge der Präferenz. Ein Server KANN (MAY) ein empfangenes Upgrade-Header-Feld ignorieren, wenn er das aktuelle Protokoll auf dieser Verbindung weiter verwenden möchte. Upgrade kann nicht verwendet werden, um auf einem Protokollwechsel zu bestehen.

Upgrade          = #protocol

protocol         = protocol-name ["/" protocol-version]
protocol-name    = token
protocol-version = token

Obwohl Protokollnamen mit einer bevorzugten Groß-/Kleinschreibung registriert sind, SOLLTEN (SHOULD) Empfänger einen case-insensitiven Vergleich verwenden, wenn sie jeden protocol-name mit unterstützten Protokollen abgleichen.

Ein Server, der eine 101 (Switching Protocols)-Antwort sendet, MUSS (MUST) ein Upgrade-Header-Feld senden, um das/die neue(n) Protokoll(e) anzuzeigen, zu dem/denen die Verbindung gewechselt wird; wenn mehrere Protokollebenen gewechselt werden, MUSS (MUST) der Sender die Protokolle in aufsteigender Ebenenreihenfolge auflisten. Ein Server DARF NICHT (MUST NOT) zu einem Protokoll wechseln, das vom Client im Upgrade-Header-Feld der entsprechenden Anfrage nicht angegeben wurde. Ein Server KANN (MAY) die vom Client angegebene Präferenzreihenfolge ignorieren und das/die neue(n) Protokoll(e) basierend auf anderen Faktoren auswählen, wie der Art der Anfrage oder der aktuellen Last des Servers.

Ein Server, der eine 426 (Upgrade Required)-Antwort sendet, MUSS (MUST) ein Upgrade-Header-Feld senden, um die akzeptablen Protokolle in absteigender Reihenfolge der Präferenz anzuzeigen.

Ein Server KANN (MAY) ein Upgrade-Header-Feld in jeder anderen Antwort senden, um anzukündigen, dass er Unterstützung für das Upgrade zu den aufgelisteten Protokollen implementiert, in absteigender Reihenfolge der Präferenz, wenn dies für eine zukünftige Anfrage angemessen ist.

Das Folgende ist ein hypothetisches Beispiel, das von einem Client gesendet wird:

GET /hello HTTP/1.1
Host: www.example.com
Connection: upgrade
Upgrade: websocket, IRC/6.9, RTA/x11

Die Fähigkeiten und die Art der Kommunikation auf Anwendungsebene nach dem Protokollwechsel hängen vollständig vom/von den gewählten neuen Protokoll(en) ab. Unmittelbar nach dem Senden der 101 (Switching Protocols)-Antwort wird jedoch erwartet, dass der Server weiterhin auf die ursprüngliche Anfrage antwortet, als hätte er ihr Äquivalent im neuen Protokoll erhalten (d.h., der Server hat nach dem Protokollwechsel noch eine ausstehende Anfrage zu erfüllen und wird erwartet, dies zu tun, ohne dass die Anfrage wiederholt werden muss).

Wenn beispielsweise das Upgrade-Header-Feld in einer GET-Anfrage empfangen wird und der Server entscheidet, das Protokoll zu wechseln, antwortet er zuerst mit einer 101 (Switching Protocols)-Nachricht in HTTP/1.1 und folgt dann unmittelbar mit dem Äquivalent des neuen Protokolls einer Antwort auf ein GET auf die Zielressource. Dies ermöglicht es, eine Verbindung zu Protokollen mit der gleichen Semantik wie HTTP ohne die Latenzkosten eines zusätzlichen Roundtrips zu aktualisieren. Ein Server DARF NICHT (MUST NOT) das Protokoll wechseln, es sei denn, die empfangene Nachrichtensemantik kann vom neuen Protokoll eingehalten werden; eine OPTIONS-Anfrage kann von jedem Protokoll eingehalten werden.

Das Folgende ist ein Beispiel für eine Antwort auf die obige hypothetische Anfrage:

HTTP/1.1 101 Switching Protocols
Connection: upgrade
Upgrade: websocket

[... Datenstrom wechselt zu websocket mit einer angemessenen Antwort
(wie durch das neue Protokoll definiert) auf die「GET /hello」-Anfrage ...]

Ein Sender von Upgrade MUSS (MUST) auch eine「Upgrade」-Verbindungsoption im Connection-Header-Feld (Section 7.6.1) senden, um Intermediäre zu informieren, dieses Feld nicht weiterzuleiten. Ein Server, der ein Upgrade-Header-Feld in einer HTTP/1.0-Anfrage empfängt, MUSS (MUST) dieses Upgrade-Feld ignorieren.

Ein Client kann nicht beginnen, ein aktualisiertes Protokoll auf der Verbindung zu verwenden, bis er die Anfragenachricht vollständig gesendet hat (d.h., der Client kann das Protokoll, das er sendet, nicht mitten in einer Nachricht ändern). Wenn ein Server sowohl ein Upgrade- als auch ein Expect-Header-Feld mit der「100-continue」-Erwartung (Section 10.1.1) empfängt, MUSS (MUST) der Server eine 100 (Continue)-Antwort senden, bevor er eine 101 (Switching Protocols)-Antwort sendet.

Das Upgrade-Header-Feld gilt nur für das Wechseln von Protokollen über der bestehenden Verbindung; es kann nicht verwendet werden, um das zugrunde liegende Verbindungs-(Transport-)Protokoll zu wechseln oder die bestehende Kommunikation auf eine andere Verbindung umzustellen. Für diese Zwecke ist es angemessener, eine 3xx (Redirection)-Antwort (Section 15.4) zu verwenden.

Diese Spezifikation definiert nur den Protokollnamen「HTTP」zur Verwendung durch die Familie der Hypertext-Transfer-Protokolle, wie durch die HTTP-Versionsregeln von Section 2.5 und zukünftige Aktualisierungen dieser Spezifikation definiert. Zusätzliche Protokollnamen sollten unter Verwendung des in Section 16.7 definierten Registrierungsverfahrens registriert werden.