1. Einführung (Introduction)

Das Hypertext Transfer Protocol (HTTP) [RFC7230] bietet kompatible Semantik auf Ressourcenebene über verschiedene Versionen hinweg, bietet jedoch keine Kompatibilität auf Verbindungsebene. Andere Protokolle, die auf Verbindungsverwaltungsdetails von HTTP angewiesen sind, wie z. B. WebSockets, müssen für neue Versionen von HTTP aktualisiert werden.

Das WebSocket-Protokoll [RFC6455] verwendet den HTTP/1.1-Upgrade-Mechanismus (Abschnitt 6.7 von [RFC7230]), um eine TCP-Verbindung von HTTP in eine WebSocket-Verbindung zu überführen. Bei HTTP/2 [RFC7540] muss ein anderer Ansatz gewählt werden. Aufgrund seiner Multiplexing-Natur erlaubt HTTP/2 keine verbindungsweiten Header-Felder oder Statuscodes, wie z. B. die Upgrade- und Connection-Anforderungs-Header-Felder oder den Antwortcode 101 (Switching Protocols). Diese sind alle für den Eröffnungs-Handshake von [RFC6455] erforderlich.

Die Möglichkeit, WebSockets von HTTP/2 zu bootstrappen, ermöglicht es, dass eine TCP-Verbindung von beiden Protokollen gemeinsam genutzt wird, und erweitert die effizientere Nutzung des Netzwerks durch HTTP/2 auf WebSockets.

Dieses Dokument erweitert die HTTP CONNECT-Methode, wie sie für HTTP/2 in Abschnitt 8.3 von [RFC7540] spezifiziert ist. Die Erweiterung ermöglicht die Ersetzung eines neuen Protokollnamens, zu dem eine Verbindung hergestellt werden soll, anstelle des externen Hosts, der normalerweise von CONNECT verwendet wird. Das Ergebnis ist ein Tunnel auf einem einzelnen HTTP/2-Stream, der Daten für WebSockets (oder jedes andere Protokoll) übertragen kann. Die anderen Streams auf der Verbindung können weitere erweiterte CONNECT-Tunnel, herkömmliche HTTP/2-Daten oder eine Mischung aus beidem übertragen.

Dieser getunnelte Stream wird mit anderen regulären Streams auf der Verbindung gemultiplext und genießt die normalen Prioritäts-, Stornierungs- und Flusssteuerungsfunktionen von HTTP/2.

Streams, die erfolgreich eine WebSocket-Verbindung unter Verwendung eines getunnelten Streams und der in diesem Dokument definierten Änderungen am Eröffnungs-Handshake herstellen, verwenden dann das traditionelle WebSocket-Protokoll und behandeln den Stream so, als wäre es die in [RFC6455] genannte TCP-Verbindung.