Zusammenfassung

  • Upgrade und CONNECT schlagen eine Veränderung der verbleibenden HTTP/1.1-Verbindung vor; erst die Antwort entscheidet über ihre Annahme.
  • Bei einer Ablehnung kann der Empfänger nachfolgende, vorab gesendete Bytes weiterhin als HTTP/1.1 lesen.

Die Abkürzung wirkt auf den ersten Blick harmlos. Der Client hat seine Nachricht beendet, kennt den gewünschten nächsten Protokollzustand und möchte keinen zusätzlichen Round Trip abwarten. Er kann daher die ersten Daten dieses Zustands schon senden. Daraus folgt jedoch nur, dass der Client eine Erwartung hatte. Der Server kann das Upgrade ignorieren, Authentisierung verlangen, umleiten, ein CONNECT-Ziel aus lokaler Policy ablehnen oder es nicht erreichen. Er hat seine Auslegungsentscheidung noch nicht mitgeteilt.

RFC 9931 benennt die sichtbaren Schwellen: 101 Switching Protocols für ein akzeptiertes Upgrade und eine erfolgreiche 2xx-Antwort für ein akzeptiertes CONNECT. Eine vollständige Anfrage ist Voraussetzung, damit ein Client in ein aktualisiertes Protokoll starten kann; sie ersetzt nicht die Bestätigung. Bis zur Antwort ist das Recht, nachfolgende Bytes anders zu parsen, nicht entstanden. Das ist keine Verzögerungsmetapher, sondern eine Grenze der Zuständigkeit.

Bei einer Ablehnung bleibt diese Grenze besonders wichtig. Der Server kann die Verbindung weiter unter der HTTP/1.1-Grammatik verarbeiten. Somit kann dieselbe Bytefolge auf einer Seite als Beginn eines neuen Protokolls und auf der anderen als weitere HTTP-Anfrage erscheinen. Ein Paket trägt seine Protokollidentität nicht unabhängig von dem Parser, der dazu berechtigt ist, sie festzulegen.

Kritisch wird die Situation, wenn ein gegenüber dem Server vertrauenswürdiger Client Daten einer nicht vertrauenswürdigen dritten Partei transportiert. Ein Browser kann Inhalte einer anderen Origin übermitteln; ein Proxy-Client kann ein TCP-Payload einer lokalen Anwendung weiterreichen. Wird dieses Payload vor einer 2xx-Antwort geschickt und CONNECT abgelehnt, kann der Proxy es noch als HTTP/1.1-Input behandeln. RFC 9931 beschreibt Request Smuggling und das Ausnutzen abweichender Parserannahmen als bedingte Risiken. Sie behauptet weder einen konkreten Vorfall noch, dass jede Optimierung bereits ein Angriff sei.

Die Aktualisierung von connect-udp zieht eine absichtlich enge Linie. Optimistische UDP-Datagramme sind nur über HTTP/2 oder später zulässig; bei HTTP/1.x sind sie wegen des Smuggling-Risikos verboten. Daraus wird kein Vertrauensurteil über HTTP/2. Die Regel weist weder eine Zielerreichung noch eine zugelassene Anwendung oder eine eingetretene Wirkung nach. Sie verhindert nur, dass eine ungeklärte HTTP/1.x-Interpretation als Performancekosten an den Empfänger ausgelagert wird.

Für Proxy-Clients, die CONNECT im Auftrag nicht vertrauenswürdiger TCP-Clients verwenden, verlangt der RFC, vor dem Weiterleiten eines Payloads auf 2xx zu warten oder Connection: close zu senden. Lehnt der Proxy CONNECT ab, muss er die zugrunde liegende Verbindung schließen, bevor er weitere Requests verarbeitet. Das sind Kontrollen gegen Mehrdeutigkeit. Sie beweisen weder die Identität einer Verbindung noch ihre Autorisierung oder den Erfolg einer Anwendung.

Ein belastbarer Datensatz bleibt deshalb bei einzelnen Verben: Client schlug vor; Request war vollständig; Antwort wurde beobachtet; Übergang wurde angenommen oder abgelehnt; Payload wurde zurückgehalten oder weitergeleitet; Verbindung wurde geschlossen; ein nachgelagertes Ergebnis wurde beobachtet. Heng Lus Vorrang für laufenden Code ist mit dieser Disziplin vereinbar. Laufende Systeme liefern Belege für ihren eigenen Beobachtungspunkt, sie dürfen daraus aber keine fremde Policy-Entscheidung oder ungemessene Wirkung machen.

Quellen