6. Verbindungsverwaltung

Die HTTP-Nachrichtenübermittlung ist unabhängig von den zugrunde liegenden Verbindungsprotokollen der Transport- oder Sitzungsschicht. HTTP setzt lediglich einen zuverlässigen Transport mit Zustellung der Anfragen in der richtigen Reihenfolge und entsprechender Zustellung der Antworten in der richtigen Reihenfolge voraus. Die Abbildung der HTTP-Anfrage- und -Antwortstrukturen auf die Dateneinheiten eines zugrunde liegenden Transportprotokolls liegt außerhalb des Geltungsbereichs dieser Spezifikation.

Wie in Abschnitt 5.2 beschrieben, werden die für eine HTTP-Interaktion zu verwendenden spezifischen Verbindungsprotokolle durch die Client-Konfiguration und den Ziel-URI bestimmt. Beispielsweise zeigt das "http"-URI-Schema (Abschnitt 2.7.1) eine Standardverbindung von TCP über IP mit einem Standard-TCP-Port von 80 an, doch der Client könnte so konfiguriert sein, dass er einen Proxy über eine andere Verbindung, einen anderen Port oder ein anderes Protokoll verwendet.

Von HTTP-Implementierungen wird erwartet, dass sie Verbindungsverwaltung betreiben, was das Pflegen des Zustands aktueller Verbindungen, das Aufbauen einer neuen Verbindung oder Wiederverwenden einer bestehenden Verbindung, das Verarbeiten von auf einer Verbindung empfangenen Nachrichten, das Erkennen von Verbindungsfehlern und das Schließen jeder Verbindung umfasst. Die meisten Clients unterhalten mehrere Verbindungen parallel, darunter mehr als eine Verbindung pro Server-Endpunkt. Die meisten Server sind darauf ausgelegt, Tausende gleichzeitiger Verbindungen zu unterhalten, während sie Anforderungswarteschlangen steuern, um eine faire Nutzung zu ermöglichen und Denial-of-Service-Angriffe zu erkennen.

6.1. Connection

Das Header-Feld "Connection" ermöglicht es dem Absender, gewünschte Steueroptionen für die aktuelle Verbindung anzugeben. Um downstream-Empfänger nicht zu verwirren, MUSS ein Proxy oder Gateway alle empfangenen Verbindungsoptionen entfernen oder ersetzen, bevor er die Nachricht weiterleitet.

Wird ein anderes Header-Feld als Connection verwendet, um Steuerinformationen für oder über die aktuelle Verbindung bereitzustellen, muss der Absender den entsprechenden Feldnamen im Header-Feld Connection auflisten. Ein Proxy oder Gateway muss ein empfangenes Header-Feld Connection parsen, bevor eine Nachricht weitergeleitet wird, und für jede connection-option in diesem Feld alle Header-Felder aus der Nachricht entfernen, die denselben Namen wie die connection-option haben, und dann das Header-Feld Connection selbst entfernen (oder es durch die eigenen Verbindungsoptionen des Vermittlers für die weitergeleitete Nachricht ersetzen).

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

Der Wert des Header-Felds Connection hat die folgende Grammatik:

Connection        = 1#connection-option
connection-option = token

Verbindungsoptionen sind case-insensitiv.

Ein Absender darf KEINE Verbindungsoption senden, die einem Header-Feld entspricht, das für alle Empfänger des Payloads bestimmt ist. Beispielsweise ist Cache-Control niemals als Verbindungsoption geeignet (Abschnitt 5.2 von [RFC7234]).

Die Verbindungsoptionen entsprechen nicht immer einem in der Nachricht vorhandenen Header-Feld, da ein verbindungsspezifisches Header-Feld möglicherweise nicht benötigt wird, wenn keine Parameter mit einer Verbindungsoption verbunden sind. Im Gegensatz dazu zeigt ein verbindungsspezifisches Header-Feld, das ohne eine entsprechende Verbindungsoption empfangen wird, üblicherweise an, dass das Feld von einem Vermittler unsachgemäß weitergeleitet wurde und vom Empfänger ignoriert werden sollte.

Bei der Definition neuer Verbindungsoptionen sollten Spezifikationsautoren bestehende Header-Feldnamen untersuchen und sicherstellen, dass die neue Verbindungsoption nicht denselben Namen wie ein bereits eingesetztes Header-Feld hat. Die Definition einer neuen Verbindungsoption reserviert im Wesentlichen diesen potenziellen Feldnamen für die Übertragung zusätzlicher Informationen im Zusammenhang mit der Verbindungsoption, da es unklug wäre, wenn Absender diesen Feldnamen für etwas anderes verwenden würden.

Die Verbindungsoption "close" ist dafür definiert, dass ein Absender signalisiert, dass diese Verbindung nach Abschluss der Antwort geschlossen wird. Zum Beispiel

Connection: close

zeigt in den Anforderungs- oder Antwort-Header-Feldern an, dass der Absender die Verbindung schließen wird, nachdem die aktuelle Anfrage/Antwort abgeschlossen ist (Abschnitt 6.6).

Ein Client, der keine persistenten Verbindungen unterstützt, MUSS die Verbindungsoption "close" in jeder Anforderungsnachricht senden.

Ein Server, der keine persistenten Verbindungen unterstützt, MUSS die Verbindungsoption "close" in jeder Antwortnachricht senden, die keinen Statuscode 1xx (Informational) hat.

6.2. Verbindungsaufbau

Es liegt außerhalb des Geltungsbereichs dieser Spezifikation zu beschreiben, wie Verbindungen über verschiedene Protokolle der Transport- oder Sitzungsschicht aufgebaut werden. Jede Verbindung gilt nur für eine Transportschicht-Verbindung (transport link).

6.3. Persistenz

HTTP/1.1 verwendet standardmäßig "persistente Verbindungen" (persistent connections), die es ermöglichen, mehrere Anfragen und Antworten über eine einzelne Verbindung zu übertragen. Die Verbindungsoption "close" wird verwendet, um zu signalisieren, dass eine Verbindung nach der aktuellen Anfrage/Antwort nicht persistent bleibt. HTTP-Implementierungen SOLLTEN persistente Verbindungen unterstützen.

Ein Empfänger bestimmt anhand der Protokollversion und des Header-Felds Connection (falls vorhanden) der zuletzt empfangenen Nachricht, ob eine Verbindung persistent ist oder nicht:

• Ist die Verbindungsoption "close" vorhanden, bleibt die Verbindung nach der aktuellen Antwort nicht persistent; andernfalls,

• ist das empfangene Protokoll HTTP/1.1 (oder später), bleibt die Verbindung nach der aktuellen Antwort persistent; andernfalls,

• ist das empfangene Protokoll HTTP/1.0, ist die Verbindungsoption "keep-alive" vorhanden, ist der Empfänger kein Proxy und möchte der Empfänger den HTTP/1.0-"keep-alive"-Mechanismus befolgen, bleibt die Verbindung nach der aktuellen Antwort persistent; andernfalls,

• wird die Verbindung nach der aktuellen Antwort geschlossen.

Ein Client KANN weitere Anfragen auf einer persistenten Verbindung senden, bis er eine Verbindungsoption "close" sendet oder empfängt oder eine HTTP/1.0-Antwort ohne eine Verbindungsoption "keep-alive" empfängt.

Um persistent zu bleiben, müssen alle Nachrichten auf einer Verbindung eine selbstdefinierte Nachrichtenlänge haben (d. h. eine, die nicht durch das Schließen der Verbindung definiert wird), wie in Abschnitt 3.3 beschrieben. Ein Server MUSS den gesamten Anforderungsnachrichtenkörper lesen oder die Verbindung nach dem Senden seiner Antwort schließen, da sonst die verbleibenden Daten auf einer persistenten Verbindung als nächste Anfrage fehlinterpretiert würden. Ebenso MUSS ein Client den gesamten Antwortnachrichtenkörper lesen, wenn er dieselbe Verbindung für eine nachfolgende Anfrage wiederverwenden möchte.

Ein Proxy-Server darf KEINE persistente Verbindung mit einem HTTP/1.0-Client unterhalten (siehe Abschnitt 19.7.1 von [RFC2068] für Informationen und eine Erörterung der Probleme mit dem Header-Feld Keep-Alive, das von vielen HTTP/1.0-Clients implementiert wird).

Siehe Anhang A.1.2 für weitere Informationen zur Abwärtskompatibilität mit HTTP/1.0-Clients.

6.3.1. Wiederholung von Anfragen

Verbindungen können jederzeit geschlossen werden, mit oder ohne Absicht. Implementierungen sollten die Notwendigkeit antizipieren, sich von asynchronen Schließereignissen zu erholen.

Wird eine inbound-Verbindung vorzeitig geschlossen, KANN ein Client eine neue Verbindung öffnen und eine abgebrochene Abfolge von Anfragen automatisch erneut übertragen, wenn alle diese Anfragen idempotente Methoden haben (Abschnitt 4.2.2 von [RFC7231]). Ein Proxy darf nicht-idempotente Anfragen NICHT automatisch wiederholen.

Ein User Agent darf eine Anfrage mit einer nicht-idempotenten Methode NICHT automatisch wiederholen, es sei denn, er hat Mittel, um zu wissen, dass die Anforderungssemantik unabhängig von der Methode tatsächlich idempotent ist, oder Mittel, um zu erkennen, dass die ursprüngliche Anfrage nie angewendet wurde. Beispielsweise kann ein User Agent, der (durch Design oder Konfiguration) weiß, dass eine POST-Anfrage an eine bestimmte Ressource sicher ist, diese Anfrage automatisch wiederholen. Ebenso könnte ein User Agent, der speziell für den Betrieb auf einem Versionskontroll-Repository ausgelegt ist, sich von Teilausfallbedingungen erholen, indem er nach einer fehlgeschlagenen Verbindung die Revision(en) der Zielressource prüft, etwaige teilweise angewendete Änderungen zurücksetzt oder korrigiert und dann die fehlgeschlagenen Anfragen automatisch wiederholt.

Ein Client SOLLTE NICHT einen fehlgeschlagenen automatischen Wiederholungsversuch automatisch wiederholen.

6.3.2. Pipelining

Ein Client, der persistente Verbindungen unterstützt, KANN seine Anfragen "pipelinen" (d. h. mehrere Anfragen senden, ohne auf jede Antwort zu warten). Ein Server KANN eine Abfolge gepipelinter Anfragen parallel verarbeiten, wenn sie alle sichere Methoden haben (Abschnitt 4.2.1 von [RFC7231]), muss aber die entsprechenden Antworten in derselben Reihenfolge senden, in der die Anfragen empfangen wurden.

Ein Client, der Anfragen pipelined, SOLLTE unbeantwortete Anfragen wiederholen, wenn die Verbindung geschlossen wird, bevor er alle entsprechenden Antworten empfängt. Beim Wiederholen gepipelinter Anfragen nach einer fehlgeschlagenen Verbindung (einer Verbindung, die nicht ausdrücklich vom Server in seiner letzten vollständigen Antwort geschlossen wurde) darf ein Client NICHT unmittelbar nach dem Verbindungsaufbau pipelinen, da die erste verbleibende Anfrage in der vorherigen Pipeline eine Fehlerantwort verursacht haben könnte, die erneut verloren gehen kann, wenn mehrere Anfragen auf einer vorzeitig geschlossenen Verbindung gesendet werden (siehe das in Abschnitt 6.6 beschriebene TCP-Reset-Problem).

Idempotente Methoden (Abschnitt 4.2.2 von [RFC7231]) sind für Pipelining signifikant, weil sie nach einem Verbindungsfehler automatisch wiederholt werden können. Ein User Agent SOLLTE NICHT Anfragen nach einer nicht-idempotenten Methode pipelinen, bis der endgültige Antwortstatuscode für diese Methode empfangen wurde, es sei denn, der User Agent hat Mittel, um Teilausfallbedingungen im Zusammenhang mit der gepipelten Abfolge zu erkennen und sich davon zu erholen.

Ein Vermittler, der gepipelte Anfragen empfängt, KANN diese Anfragen beim Weiterleiten inbound pipelinen, da er sich darauf verlassen kann, dass der bzw. die outbound-User-Agent(s) bestimmen, welche Anfragen sicher gepipelined werden können. Schlägt die inbound-Verbindung vor dem Empfang einer Antwort fehl, KANN der pipelinende Vermittler versuchen, eine Abfolge von Anfragen zu wiederholen, die noch keine Antwort erhalten haben, wenn die Anfragen alle idempotente Methoden haben; andernfalls SOLLTE der pipelinende Vermittler alle empfangenen Antworten weiterleiten und dann die entsprechende(n) outbound-Verbindung(en) schließen, damit sich der bzw. die outbound-User-Agent(s) entsprechend erholen können.

6.4. Nebenläufigkeit

Ein Client sollte die Anzahl gleichzeitig geöffneter Verbindungen, die er zu einem bestimmten Server unterhält, begrenzen.

Frühere Revisionen von HTTP gaben eine bestimmte Anzahl von Verbindungen als Obergrenze an, aber dies erwies sich für viele Anwendungen als unpraktisch. Infolgedessen schreibt diese Spezifikation keine bestimmte maximale Anzahl von Verbindungen vor, sondern ermutigt Clients, beim Öffnen mehrerer Verbindungen konservativ zu sein.

Mehrere Verbindungen werden typischerweise verwendet, um das Problem des "Head-of-Line-Blocking" zu vermeiden, bei dem eine Anfrage, die erhebliche serverseitige Verarbeitung erfordert und/oder einen großen Payload hat, nachfolgende Anfragen auf derselben Verbindung blockiert. Jede Verbindung verbraucht jedoch Serverressourcen. Darüber hinaus kann die Verwendung mehrerer Verbindungen in überlasteten Netzwerken unerwünschte Nebenwirkungen verursachen.

Beachten Sie, dass ein Server Verkehr ablehnen kann, den er als missbräuchlich oder als charakteristisch für einen Denial-of-Service-Angriff ansieht, etwa eine übermäßige Anzahl offener Verbindungen von einem einzelnen Client.

6.5. Fehler und Timeouts

Server haben üblicherweise einen Timeout-Wert, nach dessen Überschreitung sie eine inaktive Verbindung nicht mehr aufrechterhalten. Proxy-Server könnten diesen Wert höher ansetzen, da es wahrscheinlich ist, dass der Client mehr Verbindungen über denselben Proxy-Server herstellt. Die Verwendung persistenter Verbindungen stellt keine Anforderungen an die Länge (oder das Vorhandensein) dieses Timeouts, weder für den Client noch für den Server.

Ein Client oder Server, der eine Zeitüberschreitung wünscht, SOLLTE ein ordnungsgemäßes Schließen der Verbindung einleiten. Implementierungen SOLLTEN offene Verbindungen ständig auf ein empfangenes Schließsignal überwachen und angemessen darauf reagieren, da das zügige Schließen beider Seiten einer Verbindung die Rückgewinnung zugewiesener Systemressourcen ermöglicht.

Ein Client, Server oder Proxy KANN die Transportverbindung jederzeit schließen. Beispielsweise könnte ein Client begonnen haben, eine neue Anfrage zu senden, während der Server beschlossen hat, die "idle"-Verbindung zu schließen. Aus Sicht des Servers wird die Verbindung geschlossen, während sie inaktiv war, aus Sicht des Clients ist jedoch eine Anfrage in Bearbeitung.

Ein Server SOLLTE persistente Verbindungen, wenn möglich, aufrechterhalten und den Flusskontrollmechanismen des zugrunde liegenden Transports erlauben, vorübergehende Überlastungen aufzulösen, statt Verbindungen in der Erwartung zu beenden, dass Clients erneut versuchen. Die letztere Technik kann die Netzwerküberlastung verschärfen.

Ein Client, der einen Nachrichtenkörper sendet, SOLLTE die Netzwerkverbindung während der Übertragung der Anfrage auf eine Fehlerantwort überwachen. Sieht der Client eine Antwort, die anzeigt, dass der Server den Nachrichtenkörper nicht empfangen möchte und die Verbindung schließt, SOLLTE der Client sofort aufhören, den Körper zu senden, und seine Seite der Verbindung schließen.

6.6. Verbindungsabbau

Das Header-Feld Connection (Abschnitt 6.1) bietet eine Verbindungsoption "close", die ein Absender SOLLTE senden, wenn er die Verbindung nach dem aktuellen Anfrage/Antwort-Paar schließen möchte.

Ein Client, der eine Verbindungsoption "close" sendet, darf KEINE weiteren Anfragen auf dieser Verbindung senden (nach derjenigen, die "close" enthält) und MUSS die Verbindung schließen, nachdem er die endgültige Antwortnachricht zu dieser Anfrage gelesen hat.

Ein Server, der eine Verbindungsoption "close" empfängt, MUSS ein Schließen der Verbindung einleiten (siehe unten), nachdem er die endgültige Antwort auf die Anfrage gesendet hat, die "close" enthielt. Der Server SOLLTE eine Verbindungsoption "close" in seiner endgültigen Antwort auf dieser Verbindung senden. Der Server darf KEINE weiteren auf dieser Verbindung empfangenen Anfragen verarbeiten.

Ein Server, der eine Verbindungsoption "close" sendet, MUSS ein Schließen der Verbindung einleiten (siehe unten), nachdem er die Antwort gesendet hat, die "close" enthält. Der Server darf KEINE weiteren auf dieser Verbindung empfangenen Anfragen verarbeiten.

Ein Client, der eine Verbindungsoption "close" empfängt, MUSS aufhören, Anfragen auf dieser Verbindung zu senden, und die Verbindung schließen, nachdem er die Antwortnachricht gelesen hat, die die "close" enthält; wurden zusätzliche gepipelte Anfragen auf der Verbindung gesendet, SOLLTE der Client nicht annehmen, dass sie vom Server verarbeitet werden.

Führt ein Server ein sofortiges Schließen einer TCP-Verbindung durch, besteht ein erhebliches Risiko, dass der Client die letzte HTTP-Antwort nicht lesen kann. Empfängt der Server zusätzliche Daten vom Client auf einer vollständig geschlossenen Verbindung, etwa eine weitere Anfrage, die der Client vor dem Empfang der Serverantwort gesendet hat, wird der TCP-Stack des Servers ein Reset-Paket an den Client senden; leider kann das Reset-Paket die noch nicht quittierten Eingabepuffer des Clients löschen, bevor sie vom HTTP-Parser des Clients gelesen und interpretiert werden können.

Um das TCP-Reset-Problem zu vermeiden, schließen Server eine Verbindung typischerweise in Etappen. Zuerst führt der Server ein Half-Close durch, indem er nur die Schreibseite der Lese-/Schreibverbindung schließt. Der Server liest dann weiter von der Verbindung, bis er ein entsprechendes Schließen durch den Client empfängt oder bis der Server einigermaßen sicher ist, dass sein eigener TCP-Stack die Bestätigung des Clients für die Pakete mit der letzten Antwort des Servers empfangen hat. Schließlich schließt der Server die Verbindung vollständig.

Es ist unbekannt, ob das Reset-Problem ausschließlich bei TCP auftritt oder auch bei anderen Transportverbindungsprotokollen gefunden werden könnte.

6.7. Upgrade

Das Header-Feld "Upgrade" soll einen einfachen Mechanismus bereitstellen, um auf derselben Verbindung von HTTP/1.1 auf ein anderes Protokoll umzusteigen. Ein Client KANN eine Liste von Protokollen im Header-Feld Upgrade einer Anfrage senden, um den Server einzuladen, vor dem Senden der endgültigen Antwort auf eines oder mehrere dieser Protokolle in absteigender Präferenzreihenfolge umzuschalten. Ein Server KANN ein empfangenes Header-Feld Upgrade ignorieren, wenn er auf dieser Verbindung das aktuelle Protokoll weiterverwenden möchte. Upgrade kann nicht verwendet werden, um auf einem Protokollwechsel zu bestehen.

Upgrade          = 1#protocol

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

Ein Server, der eine 101-Antwort (Switching Protocols) sendet, MUSS ein Header-Feld Upgrade senden, um das bzw. die neuen Protokolle anzuzeigen, auf das bzw. die die Verbindung umgeschaltet wird; werden mehrere Protokollschichten umgeschaltet, muss der Absender die Protokolle in schichtaufsteigender Reihenfolge auflisten. Ein Server darf NICHT auf ein Protokoll umschalten, das vom Client im Header-Feld Upgrade der entsprechenden Anfrage nicht angegeben wurde. Ein Server KANN die vom Client angegebene Präferenzreihenfolge ignorieren und das bzw. die neue(n) Protokoll(e) anhand anderer Faktoren auswählen, etwa der Art der Anfrage oder der aktuellen Last des Servers.

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

Ein Server KANN ein Header-Feld Upgrade in einer anderen Antwort senden, um anzugeben, dass er die Unterstützung für das Upgrade auf die aufgeführten Protokolle in absteigender Präferenzreihenfolge implementiert, wenn dies für eine zukünftige Anfrage angemessen ist.

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

GET /hello.txt HTTP/1.1
Host: www.example.com
Connection: upgrade
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

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

Wenn beispielsweise das Header-Feld Upgrade in einer GET-Anfrage empfangen wird und der Server beschließt, die Protokolle umzuschalten, antwortet er zuerst mit einer 101-Nachricht (Switching Protocols) in HTTP/1.1 und lässt dann unmittelbar das Äquivalent des neuen Protokolls für eine Antwort auf eine GET auf die Zielressource folgen. Dies ermöglicht es, eine Verbindung auf Protokolle mit derselben Semantik wie HTTP aufzuwerten, ohne die Latenzkosten eines zusätzlichen Round Trips. Ein Server darf NICHT Protokolle umschalten, es sei denn, die empfangene Nachrichtensemantik kann durch das neue Protokoll erfüllt werden; eine OPTIONS-Anfrage kann durch jedes Protokoll erfüllt werden.

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

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

[... data stream switches to HTTP/2.0 with an appropriate response
(as defined by new protocol) to the "GET /hello.txt" request ...]

Wird Upgrade gesendet, muss der Absender auch ein Header-Feld Connection (Abschnitt 6.1) senden, das eine Verbindungsoption "upgrade" enthält, um zu verhindern, dass Upgrade versehentlich von Vermittlern weitergeleitet wird, die die aufgeführten Protokolle möglicherweise nicht implementieren. Ein Server muss ein Header-Feld Upgrade ignorieren, das in einer HTTP/1.0-Anfrage empfangen wird.

Ein Client kann erst dann beginnen, ein aufgewertetes Protokoll auf der Verbindung zu verwenden, wenn er die Anforderungsnachricht vollständig gesendet hat (d. h., der Client kann das von ihm gesendete Protokoll nicht mitten in einer Nachricht ändern). Empfängt ein Server sowohl ein Header-Feld Upgrade als auch ein Header-Feld Expect mit der Erwartung "100-continue" (Abschnitt 5.1.1 von [RFC7231]), muss der Server eine 100-Antwort (Continue) senden, bevor er eine 101-Antwort (Switching Protocols) sendet.

Das Header-Feld Upgrade gilt nur für das Umschalten von Protokollen auf der bestehenden Verbindung; es kann nicht verwendet werden, um das zugrunde liegende Verbindungs(transport)protokoll umzuschalten, noch um die bestehende Kommunikation auf eine andere Verbindung umzuschalten. Für diese Zwecke ist es angemessener, eine 3xx-Antwort (Redirection) zu verwenden (Abschnitt 6.4 von [RFC7231]).

Diese Spezifikation definiert nur den Protokollnamen "HTTP" für die Verwendung durch die Familie der Hypertext Transfer Protocols, wie durch die HTTP-Versionsregeln von Abschnitt 2.6 und zukünftige Aktualisierungen dieser Spezifikation definiert. Zusätzliche Token sollten bei IANA unter Verwendung des in Abschnitt 8.6 definierten Registrierungsverfahrens registriert werden.