Resumen

  • Según RFC 9110, un cliente puede enviar Upgrade para invitar a un cambio de protocolo en la misma conexión, pero el servidor puede ignorarlo y un intermediario debe retirar el campo específico de la conexión antes del reenvío ordinario.
  • Probar una transición completa exige una respuesta válida 101 Switching Protocols que seleccione un protocolo ofrecido, la finalización de la petición original y el primer intercambio válido bajo el protocolo nuevo.

Imaginemos un panel de migración que encuentra Upgrade: websocket en una petición y marca de inmediato la sesión como “WebSocket activo”. Entre el cliente y el origen, un proxy aplica el campo Connection y elimina la invitación limitada a ese enlace. El origen nunca la ve y responde 200 OK en HTTP/1.1. Ningún extremo cambia de protocolo, pero el panel registra una migración porque convierte una oferta en un resultado.

Es un caso hipotético, no un informe sobre un proveedor concreto. El fallo está en la prueba: una cabecera vista en un punto no establece un cambio de estado que requiere observaciones ordenadas a ambos lados de una frontera.

RFC 9110 define Upgrade como un mecanismo para pasar de HTTP/1.1 a otro protocolo sobre la misma conexión. El cliente puede enviar una lista ordenada de protocolos para invitar al servidor a cambiar según sus preferencias. El servidor puede ignorar la invitación. Por tanto, el campo expresa disposición y preferencia, no aceptación, éxito de negociación ni disponibilidad real.

La invitación es específica de la conexión. Quien envía Upgrade debe incluir también upgrade en el campo Connection. Esa regla impide que los intermediarios propaguen sin criterio la opción recibida. Antes de reenviar el mensaje, un intermediario elimina los campos nombrados por Connection. Si un proxy admite el protocolo solicitado y decide invitar al siguiente salto, puede generar un nuevo Upgrade específico de ese enlace y debe incluir upgrade en su propio Connection. Una captura en el borde del cliente no demuestra, por tanto, que el origen recibiera la misma oferta; una captura en el origen tampoco prueba que el cliente recibiera intacta una respuesta posterior. Un servidor HTTP/1.0 que reciba Upgrade debe ignorarlo.

La aceptación válida tiene una forma más estricta. El servidor que cambia de protocolo debe enviar 101 Switching Protocols con un campo Upgrade que identifique el protocolo elegido. No debe seleccionar uno que el cliente no ofreció. Así, 101 es un límite de decisión: antes, el cliente propone; después de una respuesta válida, ambas partes acuerdan reinterpretar la misma conexión.

Ni siquiera la línea 101 constituye todo el recibo. El cliente no puede comenzar el protocolo nuevo hasta enviar por completo la petición que llevó la invitación. El servidor no debe cambiar si el protocolo nuevo no puede respetar la semántica del mensaje recibido. Después del cambio, se espera que el servidor continúe respondiendo a la petición original de forma equivalente a una respuesta HTTP dentro del protocolo seleccionado. La prueba operativa necesita el final de la petición y el primer intercambio bien formado, no solo un código de estado en un registro.

El mecanismo no sustituye el transporte subyacente ni crea otra conexión. Cambia únicamente el protocolo de aplicación superior en la conexión existente. Si la telemetría une una oferta de una conexión con un 101 o una trama de otra, fabrica una transición que la norma no describe. La identidad de conexión, el orden de bytes y la dirección de captura son esenciales.

Este análisis no repite R067 sobre la cobertura de Via, R064 sobre si Alt-Svc prueba una ruta alternativa, el trabajo Strategic Local sobre restauración de prioridades ni B842 sobre correlación de identificadores IPv6 temporales. El objeto aquí es un cambio de protocolo de aplicación ligado a una conexión y su prueba es un recibo ordenado de negociación e intercambio.

Un recibo sólido une la petición exacta, las ofertas ordenadas, los tokens de Connection, observaciones antes y después de cada intermediario, el estado final, el protocolo seleccionado, el final de los bytes de petición, el punto de cambio, el primer mensaje válido del nuevo protocolo y cualquier repliegue o cierre. Este registro no es un elemento de protocolo definido por la IETF, sino una síntesis editorial de evidencias operativas. “Oferta observada” nunca debe convertirse en “cambio completado”.

Fuentes