Resumen

  • Un proxy abre una conexión TCP por el cliente. CONNECT clásico indica el host y el puerto de destino, pero no identifica el servicio proxy que abre el túnel; CONNECT-TCP añade un origen y una ruta para nombrarlo.
  • El IESG aprobó el borrador como Proposed Standard el 30 de octubre. Las pasarelas que ofrezcan compatibilidad deben traducir el mecanismo entre sus versiones HTTP. Los documentos no publican cifras de despliegue ni pruebas en producción.

Cuando un túnel no conecta, el usuario ve un destino inaccesible; la pasarela intermedia puede haber descartado la solicitud antes de que llegara. CONNECT clásico indica al proxy qué host y puerto alcanzar, pero no qué servicio proxy debe recibir la petición. CONNECT-TCP añade un origen y una ruta para identificar esa puerta. Si el servicio se aloja junto a otros en el mismo servidor, esa distinción deja de ser un detalle: ordena el encaminamiento y el ámbito de sus cabeceras.

El 30 de octubre, el IESG aprobó draft-ietf-httpbis-connect-tcp como Proposed Standard. La versión 17 apareció un día antes. El salto siguiente queda en cada pasarela: debe transportar el mecanismo entre las versiones HTTP que admita, sin perder la identidad del servicio ni el contexto necesario para la autenticación.

El servicio se identifica con una plantilla URI que contiene target_host y target_port. El cliente completa los campos con el destino y envía la URI resultante al proxy. En HTTP/1.1, usa GET y luego Upgrade a connect-tcp. En HTTP/2 y HTTP/3, usa Extended CONNECT con :protocol igual a connect-tcp. El proxy anuncia en sus parámetros si admite ese modo.

El flujo TCP viaja en mensajes del protocolo Capsule. DATA lleva bytes; FINAL_DATA lleva los últimos bytes y señala el cierre equivalente a FIN de TCP. Las cápsulas no intentan imitar segmentos TCP ni registros TLS: empaquetan el flujo mientras cruza HTTP.

Ahora aparece la factura. Una pasarela que prometa compatibilidad debe manejar Upgrade de HTTP/1.1 o Extended CONNECT, reenviar connect-tcp y convertir las solicitudes entre las versiones HTTP que admita. También debe dejar pasar Proxy-Status. Si el servidor de origen autentica mediante certificados de cliente TLS, la pasarela debe encargarse de esa autenticación o transmitir la información pertinente al origen.

El IETF ha escrito el traspaso en los requisitos; no ha actualizado las pasarelas. El borrador y el registro de decisiones no informan cuántas están desplegadas, cuántas podrían adoptarlo ni qué resultados de interoperabilidad existen en producción. Una norma fija la forma del mensaje. Los operadores aún deben encontrar cada proxy, intermediario y frontera de autenticación que lo toca.

Fuentes