Resumen

  • HTTP/1.1 permite solicitar que el resto de una conexión cambie de protocolo; la solicitud no equivale a que el servidor lo haya escogido.
  • Si el servidor rechaza la transición, los bytes que el cliente adelantó pueden seguir siendo interpretados como HTTP/1.1.

La optimización tiene una lógica seductora. Un cliente ya terminó su petición Upgrade o CONNECT; ha visto antes que la otra parte suele aceptarla; mantener un viaje de ida y vuelta parece un desperdicio. Envía entonces los primeros bytes de aquello que espera usar después. Desde su punto de vista, está ahorrando espera. Desde el punto de vista del receptor, todavía no existe el hecho que decidirá el lenguaje de esos bytes.

RFC 9931 conserva ese hecho en su lugar. Un servidor acepta Upgrade con 101 Switching Protocols. Un CONNECT aceptado se anuncia con un 2xx. Antes de uno de esos resultados hay una oferta, no una transición confirmada. La petición completa es una condición necesaria, no suficiente. El servidor puede ignorar el token, requerir autenticación, redirigir o rechazar el destino por política o por imposibilidad de conexión.

Cuando la respuesta es negativa, el canal no se convierte retroactivamente en otra cosa. El servidor continúa interpretando los bytes posteriores conforme a HTTP/1.1. Ahí nace el riesgo: un cliente puede haber tratado una secuencia como datos de un protocolo nuevo mientras el servidor la trata como otra solicitud HTTP. No es que un paquete posea una identidad universal. Su significado depende del parser que la respuesta aún pendiente no había seleccionado.

El RFC destaca la combinación más delicada: un cliente que merece confianza ante el servidor, pero transporta contenido escogido por un tercero no confiable. En un CONNECT de proxy, por ejemplo, la aplicación local podría entregar payload antes de que el proxy confirme el túnel. Si el destino falla y llega el rechazo, esos bytes pueden tener forma de una petición HTTP adicional. RFC 9931 llama a esto una posibilidad de request smuggling o de explotar supuestos del parser. No demuestra que sucediera contra una empresa ni convierte cada byte temprano en evidencia de ataque.

La actualización de connect-udp convierte el razonamiento en una regla clara. Los clientes pueden iniciar de forma optimista datagramas UDP únicamente con HTTP/2 o posterior; con HTTP/1.x no deben hacerlo. Tampoco es una medalla para HTTP/2: no confirma un destino, la entrega de un datagrama, la identidad del cliente ni una decisión de servicio. Limita una optimización en el lugar donde la ambigüedad de interpretación es inaceptable.

Para tráfico TCP de terceros, el cliente proxy debe esperar el 2xx antes de reenviar payload o usar Connection: close. Tras rechazar CONNECT, el proxy debe cerrar la conexión antes de procesar otra petición. Son controles de orden y de interpretación. Conviene registrarlos como tales, sin inflarlos a prueba de autorización, de sesión establecida o de resultado de aplicación.

El hábito útil es mantener una cadena de evidencia: propuesto por cliente; petición terminada; respuesta recibida; transición aceptada o rechazada; payload retenido o reenviado; conexión cerrada; efecto posterior observado. Cada línea responde una pregunta distinta. La filosofía de Heng Lu no pide sustituir evidencia técnica por retórica de gobierno; pide que cada evidencia conserve su tamaño. Una traza de ejecución puede ser verdadera sin decidir el uso local que otra organización hará de ella.

Fuentes