Zum Hauptinhalt springen

3. Kapseln (Capsules)

Ein Mechanismus zur Erweiterung von HTTP besteht darin, neue HTTP-Upgrade-Token einzuführen; siehe Abschnitt 16.7 von [HTTP]. In HTTP/1.x werden diese Token über den Upgrade-Mechanismus verwendet; siehe Abschnitt 7.8 von [HTTP]. In HTTP/2 und HTTP/3 werden diese Token über den Extended CONNECT-Mechanismus verwendet; siehe [EXT-CONNECT2] und [EXT-CONNECT3].

Diese Spezifikation führt das Kapselprotokoll (Capsule Protocol) ein. Das Kapselprotokoll ist eine Sequenz von Typ-Länge-Wert-Tupeln, die Definitionen neuer HTTP-Upgrade-Token wählen können zu verwenden. Es ermöglicht Endpunkten, anfragebezogene Informationen zuverlässig Ende-zu-Ende auf HTTP-Anforderungsströmen zu kommunizieren, selbst bei Vorhandensein von HTTP-Vermittlern. Das Kapselprotokoll kann verwendet werden, um HTTP-Datagramme auszutauschen, was notwendig ist, wenn HTTP über einen Transport läuft, der den QUIC DATAGRAM-Frame nicht unterstützt. Das Kapselprotokoll kann auch verwendet werden, um zuverlässige und bidirektionale Kontrollnachrichten zu kommunizieren, die mit einem datagrammbasierten Protokoll verbunden sind, selbst wenn HTTP/3-Datagramme verwendet werden.

3.1. HTTP-Datenströme (HTTP Data Streams)​

Diese Spezifikation definiert den „Datenstrom" (data stream) einer HTTP-Anfrage als den bidirektionalen Bytestrom, der auf den Header-Abschnitt der Anforderungsnachricht und die endgültige Antwortnachricht folgt, die entweder erfolgreich (d.h. 2xx) oder aktualisiert (d.h. 101) ist.

In HTTP/1.x besteht der Datenstrom aus allen Bytes der Verbindung, die auf die Leerzeile folgen, die entweder den Anforderungs-Header-Abschnitt oder den endgültigen Antwort-Header-Abschnitt abschließt. Daher kann nur die letzte HTTP-Anfrage auf einer HTTP/1.x-Verbindung das Kapselprotokoll starten.

In HTTP/2 und HTTP/3 besteht der Datenstrom einer gegebenen HTTP-Anfrage aus allen Bytes, die in DATA-Frames mit der entsprechenden Stream-ID gesendet werden.

Das Konzept eines Datenstroms ist besonders relevant für Methoden wie CONNECT, bei denen es nach den Headern keinen HTTP-Nachrichteninhalt gibt.

Datenströme können mit allen Mitteln priorisiert werden, die für Strom- oder Anforderungspriorisierung geeignet sind. Siehe zum Beispiel Abschnitt 11 von [PRIORITY].

Datenströme unterliegen den Flusskontrollmechanismen der zugrunde liegenden Schichten; Beispiele umfassen HTTP/2-Stromflusskontrolle, HTTP/2-Verbindungsflusskontrolle und TCP-Flusskontrolle.

3.2. Das Kapselprotokoll (The Capsule Protocol)​

Definitionen neuer HTTP-Upgrade-Token können angeben, dass der Datenstrom ihrer zugeordneten Anfrage das Kapselprotokoll verwendet. Wenn sie dies tun, verwendet der Inhalt des Datenstroms der zugeordneten Anfrage das folgende Format:

Capsule Protocol {
  Capsule (..) ...,
}

Abbildung 2: Kapselprotokoll-Stromformat

Capsule {
  Capsule Type (i),
  Capsule Length (i),
  Capsule Value (..),
}

Abbildung 3: Kapselformat

Capsule Type: Eine Ganzzahl variabler Länge, die den Typ der Kapsel angibt. Ein IANA-Register wird verwendet, um die Zuweisung von Kapseltypen zu verwalten; siehe Abschnitt 5.4.

Capsule Length: Die Länge des Capsule Value-Feldes, das auf dieses Feld folgt, in Bytes, kodiert als Ganzzahl variabler Länge. Beachten Sie, dass dieses Feld einen Wert von Null haben kann.

Capsule Value: Die Nutzlast dieser Kapsel. Ihre Semantik wird durch den Wert des Capsule Type-Feldes bestimmt.

Ein Vermittler kann die Verwendung des Kapselprotokolls entweder durch das Vorhandensein des Capsule-Protocol-Headerfeldes (Abschnitt 3.4) oder durch das Verständnis des gewählten HTTP-Upgrade-Tokens identifizieren.

Da neue Protokolle oder Erweiterungen neue Kapseltypen definieren könnten, sollten (SHOULD) Vermittler, die zukünftige Erweiterbarkeit ermöglichen möchten, Kapseln ohne Änderung weiterleiten, es sei denn, die Definition des verwendeten Kapseltyps spezifiziert zusätzliche Vermittlerverarbeitung. Ein solcher Kapseltyp ist die DATAGRAM-Kapsel; siehe Abschnitt 3.5. Insbesondere sollten (SHOULD) Vermittler Kapseln mit einem unbekannten Kapseltyp ohne Änderung weiterleiten.

Endpunkte, die eine Kapsel mit einem unbekannten Kapseltyp empfangen, müssen (MUST) diese Kapsel stillschweigend verwerfen und sie überspringen, um die nächste Kapsel zu analysieren.

Aufgrund der Definition des Datenstroms:

  • Das Kapselprotokoll wird nicht verwendet, es sei denn, die Antwort enthält einen 2xx (Erfolg)- oder 101 (Protokollwechsel)-Statuscode.

  • Wenn das Kapselprotokoll verwendet wird, transportieren die zugehörige HTTP-Anfrage und -Antwort keinen HTTP-Inhalt. Eine zukünftige Erweiterung kann (MAY) einen neuen Kapseltyp definieren, um HTTP-Inhalt zu transportieren.

Das Kapselprotokoll gilt nur für Definitionen neuer HTTP-Upgrade-Token; daher kann es in HTTP/2 und HTTP/3 nur mit der CONNECT-Methode verwendet werden. Daher ändern sich die Frame-Nutzungsanforderungen des Stroms, wie in Abschnitt 8.5 von [HTTP/2] und Abschnitt 4.4 von [HTTP/3] spezifiziert, sobald beide Endpunkte der Verwendung des Kapselprotokolls zustimmen.

Das Kapselprotokoll darf (MUST NOT) nicht mit Nachrichten verwendet werden, die Content-Length-, Content-Type- oder Transfer-Encoding-Headerfelder enthalten. Zusätzlich dürfen (MUST NOT) die HTTP-Statuscodes 204 (No Content), 205 (Reset Content) und 206 (Partial Content) nicht auf Antworten gesendet werden, die das Kapselprotokoll verwenden. Ein Empfänger, der eine Verletzung dieser Anforderungen beobachtet, muss (MUST) die HTTP-Nachricht als fehlerhaft behandeln.

Bei der Verarbeitung von Kapseln könnte ein Empfänger versucht sein, die volle Länge des Capsule Value-Feldes im Datenstrom zu akkumulieren, bevor er es verarbeitet. Dieser Ansatz sollte (SHOULD) vermieden werden, da er die Flusskontrolle in den zugrunde liegenden Schichten verbrauchen kann, was zu Deadlocks führen kann, wenn die Kapseldaten das Flusskontrollfenster erschöpfen.

3.3. Fehlerbehandlung (Error Handling)​

Wenn ein Empfänger beim Verarbeiten des Kapselprotokolls auf einen Fehler stößt, muss (MUST) der Empfänger ihn so behandeln, als hätte er eine fehlerhafte oder unvollständige HTTP-Nachricht erhalten. Für HTTP/3 ist die Behandlung fehlerhafter Nachrichten in Abschnitt 4.1.2 von [HTTP/3] beschrieben. Für HTTP/2 ist die Behandlung fehlerhafter Nachrichten in Abschnitt 8.1.1 von [HTTP/2] beschrieben. Für HTTP/1.x ist die Behandlung unvollständiger Nachrichten in Abschnitt 8 von [HTTP/1.1] beschrieben.

Die Nutzlast jeder Kapsel muss (MUST) genau die in ihrer Beschreibung identifizierten Felder enthalten. Eine Kapselnutzlast, die zusätzliche Bytes nach den identifizierten Feldern enthält, oder eine Kapselnutzlast, die vor dem Ende der identifizierten Felder endet, muss (MUST) so behandelt werden, als wäre sie eine fehlerhafte oder unvollständige Nachricht. Insbesondere müssen (MUST) redundante Längenkodierungen auf Selbstkonsistenz überprüft werden.

Wenn die Empfangsseite eines Stroms, der Kapseln transportiert, sauber beendet wird (zum Beispiel ist dies in HTTP/3 als Empfang eines QUIC STREAM-Frames mit gesetztem FIN-Bit definiert) und die letzte Kapsel auf dem Strom abgeschnitten wurde, muss (MUST) dies so behandelt werden, als wäre es eine fehlerhafte oder unvollständige Nachricht.

3.4. Das Capsule-Protocol-Headerfeld (The Capsule-Protocol Header Field)​

Das „Capsule-Protocol"-Headerfeld ist ein strukturiertes Item-Feld; siehe Abschnitt 3.3 von [STRUCTURED-FIELDS]. Sein Wert muss (MUST) ein Boolescher Wert sein; jeder andere Werttyp muss (MUST) von Empfängern so behandelt werden, als ob das Feld nicht vorhanden wäre (wenn dieses Feld beispielsweise mehrmals enthalten ist, wird sein Typ zu einer Liste und das Feld wird ignoriert). Dieses Dokument definiert keine Parameter für den Wert des Capsule-Protocol-Headerfeldes, aber zukünftige Dokumente könnten Parameter definieren. Empfänger müssen (MUST) unbekannte Parameter ignorieren.

Endpunkte zeigen an, dass das Kapselprotokoll auf einem Datenstrom verwendet wird, indem sie ein Capsule-Protocol-Headerfeld mit einem wahren Wert senden. Ein Capsule-Protocol-Headerfeld mit einem falschen Wert hat dieselbe Semantik wie wenn der Header nicht vorhanden ist.

Vermittler können (MAY) dieses Headerfeld verwenden, um die Verarbeitung von HTTP-Datagrammen für unbekannte HTTP-Upgrade-Token zu ermöglichen. Beachten Sie, dass dies nur für HTTP Upgrade oder Extended CONNECT möglich ist.

Das Capsule-Protocol-Headerfeld darf (MUST NOT) nicht auf HTTP-Antworten mit einem Statuscode verwendet werden, der sowohl von 101 (Protokollwechsel) verschieden ist als auch außerhalb des 2xx (Erfolg)-Bereichs liegt.

Bei Verwendung des Kapselprotokolls sollten (SHOULD) HTTP-Endpunkte das Capsule-Protocol-Headerfeld senden, um die Vermittlerverarbeitung zu vereinfachen. Definitionen neuer HTTP-Upgrade-Token, die das Kapselprotokoll verwenden, können (MAY) diese Empfehlung ändern.

3.5. Die DATAGRAM-Kapsel (The DATAGRAM Capsule)​

Dieses Dokument definiert den DATAGRAM (0x00)-Kapseltyp. Diese Kapsel ermöglicht das Senden von HTTP-Datagrammen auf einem Strom unter Verwendung des Kapselprotokolls. Dies ist besonders nützlich, wenn HTTP über einen Transport läuft, der den QUIC DATAGRAM-Frame nicht unterstützt.

Datagram Capsule {
  Type (i) = 0x00,
  Length (i),
  HTTP Datagram Payload (..),
}

Abbildung 4: DATAGRAM-Kapselformat

HTTP Datagram Payload: Die Nutzlast des Datagramms, dessen Semantik durch die Erweiterung definiert ist, die HTTP-Datagramme verwendet. Beachten Sie, dass dieses Feld leer sein kann.

HTTP-Datagramme, die mit der DATAGRAM-Kapsel gesendet werden, haben dieselbe Semantik wie die in QUIC DATAGRAM-Frames gesendeten. Insbesondere gelten die Einschränkungen, wann es erlaubt ist, ein HTTP-Datagramm zu senden und wie sie zu verarbeiten sind (aus Abschnitt 2.1), auch für HTTP-Datagramme, die mit der DATAGRAM-Kapsel gesendet und empfangen werden.

Ein Vermittler kann HTTP-Datagramme neu kodieren, wenn er sie weiterleitet. Mit anderen Worten, ein Vermittler kann (MAY) eine DATAGRAM-Kapsel senden, um ein HTTP-Datagramm weiterzuleiten, das in einem QUIC DATAGRAM-Frame empfangen wurde, und umgekehrt. Vermittler dürfen (MUST NOT) diese Neukodierung nicht durchführen, es sei denn, sie haben die Verwendung des Kapselprotokolls auf dem entsprechenden Anforderungsstrom identifiziert; siehe Abschnitt 3.2.

Beachten Sie, dass DATAGRAM-Kapseln, die auf einem Strom gesendet werden, zwar zuverlässig in Reihenfolge zugestellt werden, Vermittler jedoch DATAGRAM-Kapseln in QUIC DATAGRAM-Frames neu kodieren können, wenn sie Nachrichten weiterleiten, was zu Verlust oder Neuordnung führen kann.

Wenn ein Vermittler ein HTTP-Datagramm in einem QUIC DATAGRAM-Frame empfängt und es auf einer Verbindung weiterleitet, die QUIC DATAGRAM-Frames unterstützt, sollte (SHOULD NOT) der Vermittler dieses HTTP-Datagramm nicht in eine DATAGRAM-Kapsel konvertieren. Wenn das HTTP-Datagramm zu groß ist, um in einen DATAGRAM-Frame zu passen (zum Beispiel, weil die Pfad-MTU (PMTU) dieser QUIC-Verbindung zu niedrig ist oder wenn die auf dieser Verbindung angekündigte maximale UDP-Nutzlastgröße zu niedrig ist), sollte (SHOULD) der Vermittler das HTTP-Datagramm verwerfen, anstatt es in eine DATAGRAM-Kapsel zu konvertieren. Dies bewahrt die Ende-zu-Ende-Unzuverlässigkeitseigenschaft, von der Methoden wie die Datagram Packetization Layer PMTU Discovery (DPLPMTUD) abhängen [DPLPMTUD]. Ein Vermittler, der QUIC DATAGRAM-Frames in DATAGRAM-Kapseln konvertiert, ermöglicht es HTTP-Datagrammen, beliebig groß zu sein, ohne Verlust zu erleiden. Dies kann die wahren Pfadeigenschaften falsch darstellen und Methoden wie DPLPMTUD zunichte machen.

Während DATAGRAM-Kapseln theoretisch eine Nutzlast der Länge 2^62-1 transportieren können, werden die meisten HTTP-Erweiterungen, die HTTP-Datagramme verwenden, eigene Grenzen für praktische Datagramm-Nutzlastgrößen haben. Implementierungen sollten (SHOULD) diese Grenzen beim Parsen von DATAGRAM-Kapseln berücksichtigen. Wenn eine eingehende DATAGRAM-Kapsel eine Länge hat, die bekanntermaßen so groß ist, dass sie nicht verwendbar ist, sollte (SHOULD) die Implementierung die Kapsel verwerfen, ohne ihren Inhalt im Speicher zu puffern.

Da QUIC DATAGRAM-Frames in ein QUIC-Paket passen müssen, könnten Implementierungen, die DATAGRAM-Kapseln in QUIC DATAGRAM-Frames neu kodieren, versucht sein, die gesamte Kapsel im Strom zu akkumulieren, bevor sie sie neu kodieren. Dies sollte (SHOULD) vermieden werden, da es Flusskontrollprobleme verursachen kann; siehe Abschnitt 3.2.

Beachten Sie, dass es für eine HTTP-Erweiterung möglich ist, HTTP-Datagramme ohne Verwendung des Kapselprotokolls zu verwenden. Wenn beispielsweise eine HTTP-Erweiterung, die HTTP-Datagramme verwendet, nur über Transporte definiert ist, die QUIC DATAGRAM-Frames unterstützen, benötigt sie möglicherweise keine Strom-Kodierung. Zusätzlich können HTTP-Erweiterungen HTTP-Datagramme mit ihrem eigenen Datenstromprotokoll verwenden. Neue HTTP-Erweiterungen, die HTTP-Datagramme verwenden möchten, sollten (SHOULD) jedoch das Kapselprotokoll verwenden, da es andernfalls für die HTTP-Erweiterung schwieriger wird, andere Versionen von HTTP als HTTP/3 zu unterstützen, und die Interoperabilität mit Vermittlern verhindert wird, die nur das Kapselprotokoll unterstützen.

Letztes Update am