Résumé

  • PTTH permet au client de transport d’ouvrir un canal que le proxy peut ensuite emprunter pour envoyer des requêtes HTTP au worker.
  • Le projet de charte place l’authentification et l’autorisation des requêtes au cœur du travail ; une connexion sortante n’accorde pas un accès général.

Le serveur d’arrière-plan ouvre la connexion. Puis le proxy le rappelle.

C’est la promesse de Protocol for Transposed Transactions over HTTP, ou PTTH : un worker derrière un pare-feu restrictif établit une connexion sortante vers un proxy, qui peut ensuite envoyer des requêtes HTTP dans ce canal. Le client de transport reçoit alors les requêtes dans le rôle de serveur HTTP.

Cette inversion peut éviter d’ouvrir un port entrant pour chaque worker ou d’attribuer une adresse fixe à chaque backend. Mais la décision difficile se déplace : une fois le canal établi, que peut demander le proxy ?

Une charte de groupe de travail proposée à l’IETF est en examen externe et inscrite au téléchat de l’IESG du 5 novembre 2026. Au 2 novembre, elle reste une proposition ; aucun standard PTTH n’est approuvé.

À l’IETF 123, en juillet 2025, les cas évoqués allaient des backends cachés à l’extension dynamique de CDN, à la priorité des requêtes, à l’accès Zero Trust et au transport d’autres protocoles sur HTTP. Un worker CDN limité à quelques chemins n’a pas la portée d’un tunnel général.

Les minutes consignent la question de pouvoir : un worker qui pousse sa configuration au proxy pourrait influer sur le routage. Les participants ont interrogé l’authentification, la limitation à une partie de l’espace URL et la frontière entre HTTP et un support pour d’autres protocoles. Les votes ont soutenu la poursuite des travaux ; ils ne mesurent pas une demande de déploiement et ne fixent pas le périmètre.

À l’IETF 126, en juillet 2026, les échanges ont séparé l’établissement du canal, l’autorisation des requêtes et la gestion de capacité. Les deux premières tâches ont été jugées essentielles au début ; la capacité dépend davantage des déploiements. Le pouvoir du worker sur la configuration du proxy a de nouveau suscité une inquiétude.

La charte proposée rend l’autorisation explicite : signaler la volonté de recevoir des requêtes, authentifier les deux parties, définir les requêtes permises et guider leur routage. La possibilité que les deux extrémités envoient sur la même connexion reste ouverte. Les nouveaux systèmes d’identité, de transport et de découverte, les demandes de capacité et toute modification de la sémantique HTTP sont exclus.

Le canal règle la joignabilité, pas l’admission, le routage ou la révocation. Des règles propres à chaque fournisseur laissent un patchwork aux opérateurs. Un standard trop ambitieux peut faire d’un canal pratique un raccourci entre frontières de confiance.

Il faut examiner l’ensemble : worker authentifié, portée autorisée, décision du proxy, expiration ou révocation et journal vérifiable. Sans cela, un tunnel fonctionnel prouve le transport, pas l’autorisation.

Sources : charte PTTH proposée par l’IETF ; minutes de l’IETF 123 ; minutes de l’IETF 126 ; brouillon individuel PTTH.