Zusammenfassung

  • Nach RFC 9110 darf ein Client mit Upgrade zu einem Protokollwechsel auf derselben Verbindung einladen; der Server darf dies ignorieren, und ein Vermittler muss das verbindungsspezifische Feld vor gewöhnlicher Weiterleitung entfernen.
  • Ein abgeschlossener Wechsel erfordert eine gültige Antwort 101 Switching Protocols, die ein angebotenes Protokoll auswählt, das Ende des ursprünglichen Requests und den ersten gültigen Austausch im neuen Protokoll.

Man stelle sich ein Migrations-Dashboard vor, das Upgrade: websocket in einem Request erkennt und die Sitzung sofort als „WebSocket aktiv“ einstuft. Zwischen Client und Ursprung entfernt jedoch ein Proxy gemäß Connection die nur für diesen Hop bestimmte Einladung. Der Ursprung sieht sie nie und antwortet regulär mit 200 OK über HTTP/1.1. Keine Seite wechselt das Protokoll; das Dashboard meldet dennoch Erfolg, weil es ein Angebot als Ergebnis behandelt.

Das Beispiel ist hypothetisch und kein Bericht über einen Anbieter. Es zeigt einen Beweisfehler: Ein Header an einem Messpunkt soll einen Zustandswechsel belegen, der geordnete Beobachtungen auf beiden Seiten einer Grenze verlangt.

RFC 9110 definiert Upgrade als Verfahren für den Wechsel von HTTP/1.1 zu einem anderen Protokoll auf derselben Verbindung. Der Client darf eine nach Präferenz geordnete Protokollliste senden und den Server zum Wechsel einladen. Der Server darf die Einladung ignorieren. Das Feld drückt Bereitschaft und Rangfolge aus, nicht Annahme, Verhandlungserfolg oder Betriebsbereitschaft.

Die Einladung ist verbindungsspezifisch. Wer Upgrade sendet, muss upgrade auch in Connection aufnehmen. Damit wird verhindert, dass Vermittler die empfangene Option blind als End-to-End-Feld weiterreichen. Ein Vermittler entfernt zunächst die in Connection genannten Felder. Unterstützt ein Proxy das verlangte Protokoll und will er den nächsten Hop einladen, kann er ein neues, für diesen Hop bestimmtes Upgrade erzeugen und muss upgrade in sein eigenes Connection-Feld der weitergeleiteten Nachricht aufnehmen. Eine clientseitige Aufzeichnung beweist daher nicht, dass der Ursprung dasselbe Angebot erhielt. Ein HTTP/1.0-Server muss einen empfangenen Upgrade-Header ignorieren.

Eine gültige Annahme hat strengere Bedingungen. Der wechselnde Server muss 101 Switching Protocols sowie ein Upgrade-Feld mit dem gewählten Protokoll senden. Er darf kein Protokoll auswählen, das der Client nicht angeboten hat. Der 101 bildet eine Entscheidungsgrenze: davor steht ein Vorschlag; erst nach einer gültigen Antwort vereinbaren beide Seiten die neue Interpretation derselben Verbindung.

Doch auch eine 101-Zeile ist noch kein vollständiger Beleg. Der Client darf das neue Protokoll erst beginnen, wenn er den einladenden Request vollständig gesendet hat. Der Server darf nicht wechseln, wenn das neue Protokoll die Semantik der empfangenen Nachricht nicht erfüllen kann. Nach dem Wechsel wird erwartet, dass der Server seine Antwort auf den ursprünglichen Request in einer HTTP-äquivalenten Form innerhalb des neuen Protokolls fortsetzt. Der Nachweis braucht daher die Request-Endgrenze und den ersten korrekt gebildeten Austausch.

Der Mechanismus ersetzt weder den darunterliegenden Transport noch erzeugt er eine zweite Verbindung. Nur das oberste Anwendungsprotokoll der bestehenden Verbindung ändert sich. Werden ein Angebot auf einer Verbindung und 101 oder neue Frames auf einer anderen verbunden, entsteht eine Transition, die der Standard nicht beschreibt. Verbindungsidentität, Bytereihenfolge und Messrichtung sind zwingend.

Diese Perspektive unterscheidet sich von R067 zur Vollständigkeit von Via, R064 zu Alt-Svc und alternativen Pfaden, Strategic Local zur Prioritätswiederherstellung sowie B842 zur Korrelation temporärer IPv6-Kennungen. Hier geht es um einen verbindungsgebundenen Wechsel des Anwendungsprotokolls und einen geordneten Verhandlungs- und Austauschbeleg.

Ein belastbarer Beleg verbindet den exakten Request, geordnete Angebote, Connection-Token, Messungen vor und nach jedem Vermittler, Endstatus, gewähltes Protokoll, Ende der Request-Bytes, genaue Umschaltstelle, erste gültige Nachricht im neuen Protokoll sowie Fallback oder Schließung. Dieser Nachweis ist kein von der IETF definiertes Protokollelement, sondern eine redaktionelle Zusammenführung betrieblicher Belege. „Angebot gesehen“ darf nie zu „Wechsel abgeschlossen“ normalisiert werden.

Quellen