Zusammenfassung

  • PTTH lässt den Transport-Client einen Kanal öffnen, über den der Proxy später HTTP-Anfragen an den Worker sendet.
  • Der Charter-Entwurf macht Authentifizierung und Anfrageberechtigung zentral; eine ausgehende Verbindung bedeutet keinen Pauschalzugriff.

Der Backend-Server öffnet die Verbindung. Danach ruft der Proxy zurück.

Das ist die Idee von PTTH: Ein Worker hinter einer restriktiven Firewall baut eine ausgehende Verbindung zum Proxy auf. Über den bestehenden Kanal kann dieser HTTP-Anfragen zurücksenden. Der Transport-Client nimmt sie in der Rolle eines HTTP-Servers entgegen.

So könnten eingehende Firewall-Ports je Worker und feste Backend-Adressen entfallen. Doch die schwierige Entscheidung rückt nur einen Hop weiter: Was darf der Proxy nach dem Verbindungsaufbau verlangen?

Ein vorgeschlagener IETF-Arbeitsauftrag steht in externer Prüfung und auf der IESG-Telechat-Agenda vom 5. November 2026. Am 2. November ist er weiterhin ein Vorschlag; ein PTTH-Standard ist nicht genehmigt.

Bei IETF 123 im Juli 2025 wurden versteckte Backends, dynamische CDN-Erweiterung, Anfragepriorisierung, Zero-Trust-Zugriff und HTTP als Träger anderer Protokolle diskutiert. Ein CDN-Worker mit wenigen erlaubten Pfaden ist kein allgemeiner Tunnel.

Die Protokolle halten die Machtfrage fest: Ein Worker, der dem Proxy Konfiguration übermittelt, könnte das Routing beeinflussen. Teilnehmende fragten nach Authentifizierung, der Begrenzung auf Teile des URL-Raums und der Grenze zwischen HTTP und einem Unterbau für andere Protokolle. Die Abstimmungen befürworteten weitere Arbeit, maßen aber weder Einführungsbedarf noch legten sie den Umfang fest.

Bei IETF 126 im Juli 2026 wurden Kanalaufbau, Autorisierung und Kapazitätssteuerung getrennt. Die ersten beiden Aufgaben galten als unverzichtbar; Kapazität und Steuerung hängen stärker von der Bereitstellung ab. Die Rechte eines Workers gegenüber der Proxy-Konfiguration blieben strittig.

Der Charter-Entwurf nennt Bereitschaft zum Empfang, beidseitige Authentifizierung, erlaubte Anfragen und Routing-Hinweise. Ob beide Endpunkte über eine Verbindung senden dürfen, bleibt offen. Neue Identitäts- und Transportsysteme, Server-Erkennung, Kapazitätsanforderungen und Änderungen an HTTP sind ausgeschlossen.

Die Verbindung schafft Erreichbarkeit, aber keine Regeln für Zulassung, Routing und Widerruf. Anbieterspezifische Regeln ergeben einen Flickenteppich. Ein zu großer Standard kann den praktischen Kanal über Vertrauensgrenzen hinweg öffnen.

Geprüft werden müssen Worker-Identität, erlaubter Anfrageumfang, Proxy-Entscheidung, Ablauf oder Widerruf und nachvollziehbares Protokoll. Sonst belegt ein Tunnel nur Transport, keine Berechtigung.

Quellen: IETF-Charterentwurf; IETF-123-Protokoll; IETF-126-Protokoll; individueller PTTH-Entwurf.