CONNECT verspricht keinen unbegrenzt offenen Tunnel. Nach einem erfolgreichen Austausch trägt die Verbindung einen fortlaufenden Bytestrom zum angeforderten Host und Port. Sie kann mehrere Austausche innerhalb einer TLS-Sitzung des Ziels tragen, solange die Beteiligten und das Netzwerk sie offen halten.

Zwei Proxy-Grenzen verhalten sich unterschiedlich: Datenverkehr kann verhindern, dass ein Idle-Timer abläuft, aber er kann keine absolute Lebenszeitgrenze verlängern. Auch das Zielprotokoll hat ein Wort mitzureden. Ein innerer HTTP-Client kann seine Verbindung schließen; eine WebSocket-Anwendung kann ihre Sitzung beenden. Der Proxy kann diese Ziel-Sitzung danach nicht am Leben halten.

Ein Tunnel ist an sein Ziel gebunden. Sobald Tunnelbytes fließen, ist die Verbindung kein gewöhnlicher HTTP-Anfragekanal mehr, auf dem ein weiteres CONNECT für ein nicht zusammenhängendes Ziel ausgestellt werden könnte. Der Client braucht eine andere Verbindung oder einen anderen Tunnel, den seine Bibliothek verwaltet.

Für einen dauerhaften Feed planen Sie Wiederverbindungen mit den vom Client unterstützten Mechanismen für Lebendigkeit und Verbindung ein. Schließt er nach Stille, ist eine Inaktivitätsrichtlinie ein nützlicher Hinweis; schließt er trotz Datenverkehr nach einer festen Dauer, untersuchen Sie stattdessen eine absolute Grenze. Für einen WebSocket-Feed stellen Sie nach dem Wiederverbinden auch den Anwendungszustand wieder her.

Ähnliche Artikel