Resumen

  • PTTH permite que el cliente de transporte abra un canal por el que el proxy puede enviar luego solicitudes HTTP al worker.
  • La carta propuesta incluye autenticación y autorización; una conexión saliente no concede acceso general.

El servidor de backend abre la conexión. Después, el proxy lo llama de vuelta.

Esa es la promesa de Protocol for Transposed Transactions over HTTP, o PTTH: un worker tras un cortafuegos restrictivo inicia una conexión saliente al proxy, y este envía solicitudes HTTP por el canal abierto. El cliente de transporte recibe esas solicitudes en el papel de servidor HTTP.

La inversión puede evitar puertos entrantes para cada worker y direcciones fijas para cada backend. Pero mueve la decisión difícil: cuando existe el canal, ¿qué puede pedirle el proxy a ese worker?

La carta propuesta para un grupo de trabajo del IETF está en revisión externa y figura en la teleconferencia del IESG del 5 de noviembre de 2026. A 2 de noviembre sigue siendo una propuesta; no hay estándar PTTH aprobado.

En el IETF 123, en julio de 2025, se presentaron backends ocultos, escalado de CDN, prioridad de solicitudes, acceso Zero Trust y HTTP como soporte de otros protocolos. Un worker de CDN limitado a ciertos caminos no equivale a un túnel general.

Las actas registran la disputa de autoridad: si el worker envía configuración al proxy, puede influir en el enrutamiento. Los asistentes preguntaron por autenticación, límites dentro del espacio URL y por cuándo HTTP deja de ser el objeto del trabajo. Las votaciones apoyaron continuar en el IETF; no midieron demanda de despliegue ni cerraron el alcance.

En el IETF 126, en julio de 2026, la discusión separó conexión, autorización y gestión de capacidad. Las dos primeras eran esenciales para el trabajo inicial; la capacidad dependía más de cada despliegue. También volvió la preocupación por el poder del worker sobre la configuración del proxy.

La carta hace explícita la autorización: señalar disposición a recibir solicitudes, autenticar ambos lados, fijar cuáles puede recibir el worker y orientar su enrutamiento. Sigue abierta la posibilidad de que ambos extremos envíen por la misma conexión. Quedan fuera nuevos sistemas de identidad, transporte o descubrimiento, solicitudes de capacidad y cambios en la semántica HTTP.

El canal resuelve conectividad, no admisión, rutas ni revocación. Reglas distintas de cada proveedor dejan un mosaico al operador. Un estándar demasiado amplio puede convertir una conexión conveniente en un atajo entre fronteras de confianza.

Hay que revisar el conjunto: worker autenticado, solicitudes permitidas, decisión del proxy, caducidad o revocación y registro auditable. Sin eso, un túnel que funciona demuestra transporte, no autorización.

Fuentes: carta PTTH propuesta por el IETF; actas del IETF 123; actas del IETF 126; borrador individual PTTH.