Resumen

  • draft-ietf-httpbis-connect-tcp-14 define el servicio mediante una plantilla URI con target_host y target_port; la expansión produce el recurso al que se dirige la conexión Capsule Protocol.
  • La plantilla selecciona origen, ruta, espacio de protección y punto de aplicación de la política. Su procedencia forma parte de la autorización, aunque la expansión sea sintácticamente correcta.
  • La Last Call del IETF termina el 1 de octubre de 2026. El texto continúa siendo un Internet-Draft, no un RFC aprobado ni evidencia de software desplegado.

La ruta al proxy dejó de ser un detalle

El CONNECT clásico presenta al proxy un host y un puerto. En la revisión 14, el cliente recibe antes una plantilla URI, sustituye los dos parámetros del destino y envía la solicitud a la URI resultante.

Esa operación elige qué origen HTTP recibe las credenciales, qué ruta sigue la pasarela y qué estado ligado al origen puede condicionar solicitudes posteriores. HSTS, Alt-Svc o las cookies ya tienen una referencia inequívoca. La misma precisión convierte la configuración en una pieza sensible: quien controla la plantilla puede cambiar el guardián del túnel.

El documento adopta las reglas de RFC 9298. La plantilla debe ser absoluta, incluir scheme, authority y path no vacíos, limitar sus variables a path o query, contener host y puerto, y evitar varios operadores de expansión. El cliente que detecte una infracción debe cancelar antes de transmitir.

La validación demuestra que la plantilla pertenece al lenguaje permitido. No demuestra quién la entregó, si tenía autoridad para modificar la salida ni si el origen corresponde al servicio administrativo esperado. La procedencia necesita su propio recibo.

Aceptar la petición no es establecer el destino

En HTTP/1.1, el cliente usa GET sobre la URI expandida y solicita Upgrade: connect-tcp. Si la petición es válida y admisible, el proxy intenta la conexión TCP antes de una respuesta final. Cuando la establece devuelve 101 Switching Protocols; si no hay conexión, no puede cambiar de protocolo.

En HTTP/2 y HTTP/3, el proxy anuncia extended CONNECT. La petición usa :protocol = connect-tcp, la autoridad del proxy y el path derivado de la plantilla. Una respuesta CONNECT satisfactoria abre el flujo para las cápsulas.

Expect: 100-continue permite observar una frontera anterior. El 100 confirma recepción y ausencia de rechazo inmediato, sin esperar al handshake con el destino. El 101 o el éxito de extended CONNECT añade que el proxy declara TCP establecido. Ninguno autentica por sí solo la aplicación remota, acepta su certificado TLS, acredita que llegaron los bytes ni confirma el efecto pedido.

La telemetría debe nombrar la fase exacta. Un 4xx por política, un fallo de resolución, una conexión rechazada y una transacción que fracasa dentro de un túnel son problemas diferentes.

La credencial pertenece al espacio del proxy

Al tener un origen propio, el proxy templado suele autenticarse con 401, WWW-Authenticate y Authorization. No usa el esquema 407 clásico porque esos campos no atraviesan una pasarela HTTP común. Los recursos generados por una plantilla comparten normalmente un protection space; también es posible un certificado TLS de cliente.

La decisión permite reutilizar autorización de usuarios, defensa DDoS, saneamiento de solicitudes y enrutamiento por ruta. Un path de alta entropía o autenticación oculta puede reducir el descubrimiento por sondeos no autorizados.

Pero una credencial válida conserva un alcance concreto. Prueba la autenticación ante el protection space del proxy. Otra política decide si ese principal puede alcanzar el host y puerto solicitados. La resolución selecciona una dirección. El TLS del destino evalúa otra identidad. La aplicación conserva la decisión sobre la operación empresarial.

RFC 9110 advierte que permitir CONNECT hacia puertos arbitrarios puede convertir al proxy en un relé para servicios imprevistos. La plantilla no elimina el riesgo; crea una superficie más clara para aplicar la restricción.

DATA conserva bytes; FINAL_DATA conserva media clausura

La carga TCP viaja en cápsulas DATA. FINAL_DATA puede llevar los últimos bytes y señala además el equivalente de un FIN en esa dirección. Después no puede aparecer otro DATA ni otro FINAL_DATA. Un FIN recibido debe convertirse en FINAL_DATA y un FINAL_DATA válido debe producir FIN hacia TCP.

Las fronteras de cápsula no corresponden necesariamente a segmentos TCP, registros TLS, tramas HTTP o mensajes de aplicación. Un intermediario puede dividir o unir cápsulas sucesivas si mantiene el orden y conserva el tipo final.

El contrato común protege una secuencia y una clausura direccional. No demuestra el significado de los bytes. El cliente puede haber escrito en el flujo mientras el proxy aún almacena datos optimistas. El proxy puede haber escrito en el socket sin que la aplicación haya procesado nada. FINAL_DATA puede transmitir un FIN aunque la dirección inversa termine abruptamente.

En HTTP/2 y HTTP/3, el proxy debe retener la carga optimista hasta que la conexión elegida sea escribible y descartarla si falla. Si compite entre varias direcciones, no puede enviar carga a las conexiones perdedoras. Por eso el registro completo separa plantilla, identidad TLS del proxy, autenticación, política, DNS, intento TCP, estado HTTP, secuencia DATA/FINAL_DATA, identidad TLS del destino, bytes entregados, cierre y resultado observado.

Una Last Call no es una instalación

El aviso del IESG solicita comentarios hasta el 1 de octubre. Datatracker muestra la revisión 14 activa, enviada al IESG y con intención de Proposed Standard.

Ese estado no equivale a aprobación. El borrador puede cambiar, ser sustituido o expirar. Incluso un RFC futuro demostraría un contrato de interoperabilidad, no soporte real en pasarelas, calidad de validación, comportamiento ante media clausura ni adopción segura.

La primacía del código en ejecución exige obtener el resultado del sistema que lo sufre. La especificación inicial mínima sitúa en la capa común sintaxis, orden y errores; la confianza en la configuración, el permiso de destino y la aceptación del resultado permanecen locales.

El proxy puede permitir el túnel. No puede convertir esa decisión en prueba universal de lo ocurrido al otro lado.

Fuentes