Resumen

  • HTTP/2 permitió reutilizar una conexión persistente y multiplexada para distintas autoridades de URI cuando la resolución y el certificado justificaban la inferencia. El cliente podía comprobar esos indicios, pero no toda la selección interna de servicio asociada al SNI de la primera conexión.
  • 421 Misdirected Request rechaza una combinación de origen y conexión. No afirma que el URI se haya trasladado, que la solicitud esté mal formada ni que TLS haya fallado. El cliente puede reintentar la misma operación por otra conexión, incluso si el método no es idempotente; un proxy ordinario no puede generar la respuesta.
  • RFC 8336 añadió la trama ORIGIN para anunciar de antemano el conjunto de orígenes admitidos en una conexión HTTP/2 y hacer que un cliente compatible retire de él un origen después de un 421. HTTP/3 mantuvo el código sobre QUIC: la cuestión permanente es quién puede hablar con autoridad en un transporte compartido.

El segundo nombre cabía en el certificado

El cliente ya tenía una conexión cifrada para un primer sitio. Quiso cargar un recurso de un segundo nombre. Ese nombre resolvía a la misma dirección y figuraba entre las identidades que el certificado del servidor podía acreditar. Abrir otra conexión parecía un gasto: una negociación más, nuevo estado de transporte y más espera antes de enviar la solicitud.

La conexión existente, además, no estaba ocupada en el sentido antiguo. HTTP/2 podía llevar varios flujos a la vez. Reutilizarla no sólo ahorraba el establecimiento; aprovechaba la propia arquitectura de multiplexación.

Sin embargo, el certificado describía identidades, no toda la disposición del centro de servicio. El SNI usado al principio pudo seleccionar un arrendatario, un frontal TLS, una regla de puerto o un grupo de servidores. Aunque el segundo nombre estuviera cubierto criptográficamente, la conexión abierta para el primero podía desembocar en un contexto que no lo atendía.

No había necesariamente un certificado falso ni una respuesta DNS equivocada. Había dos visiones legítimas y parciales. El cliente conocía razones para intentar la reutilización. El servidor conocía la configuración que impedía aceptarla. HTTP 421 permitió que la segunda visión corrigiera a la primera sin borrar el origen ni condenar toda la conexión.

Nombrar el destino no resolvía el contexto

La historia de Host había demostrado que una dirección de red no identifica por sí sola un espacio de recursos. Cuando numerosos sitios pasaron a compartir una dirección IP, HTTP/1.1 exigió que cada solicitud dijera a qué host y puerto se dirigía. En HTTP/2 y HTTP/3, el pseudocampo :authority suele transportar esa intención.

Así se contestó una pregunta del cliente: ¿qué origen quiero? Quedaba otra pregunta en manos del receptor: ¿puede este servicio producir una respuesta autorizada para ese origen en esta conexión concreta?

RFC 9110 mantiene ambas obligaciones. La autoridad de la solicitud distingue un espacio de nombres de otros que pueden convivir en un servidor. Tras reconocer el URI objetivo, el servidor sigue teniendo que decidir si procesa, reenvía, redirige, rechaza o abandona la solicitud, y debe comprobar los requisitos del esquema y del contexto de conexión.

Host impide que el servidor adivine el nombre sólo por la dirección. No convierte la intención del cliente en autoridad ejecutiva sobre cada proceso alcanzable por el socket.

La economía de HTTP/2 amplió la reutilización

La especificación original de HTTP/2, RFC 7540, apareció en mayo de 2015. Sus conexiones persistentes y flujos multiplexados daban un valor nuevo a conservar y compartir un canal. La norma permitía reutilizarlo para solicitudes con distintas autoridades de URI siempre que el servidor pareciera autorizado para ellas.

En TCP sin TLS, el nuevo host debía resolver a la misma dirección IP. En HTTPS se añadía otra condición: el certificado debía ser válido para el host según las verificaciones que el cliente habría ejecutado al abrir una conexión nueva. Una lista de nombres alternativos, o un comodín aplicable, podía sostener esa comprobación para varios orígenes.

Era una política prudente desde el lado del cliente. Evitaba que cualquier conexión sirviera cualquier nombre. Pero seguía siendo una inferencia construida con hechos exteriores.

RFC 7540 explicó el fallo con un terminador TLS que usa el SNI del establecimiento para escoger el servidor de origen. Una solicitud posterior, dirigida a otro nombre cubierto por el certificado, podía llegar a una instancia que no era su destino interno. La infraestructura era capaz de servir ambos nombres, quizá incluso en la misma dirección, pero no necesariamente dentro de la misma selección inicial.

La multiplexación unió solicitudes; no hizo uniforme el interior del servicio.

421 delimitó el rechazo

RFC 7540 introdujo 421 Misdirected Request. La definición vigente pasó después a RFC 9110, dentro de la semántica general de HTTP.

El código indica que el servidor no puede o no quiere producir una respuesta autorizada para el URI objetivo. Puede que el URI no corresponda a un origen configurado allí o que no corresponda al contexto por el que llegó la solicitud.

El objeto del rechazo es importante. El servidor no dice que el recurso haya desaparecido ni que deba buscarse en otro URI. No declara inválida toda la conexión. Dice que esa conexión no es el lugar desde el que él puede hablar por ese origen.

Puede emitir 421 el servidor de origen o una pasarela que actúe en nombre del origen. Un proxy no puede generarlo. La prohibición de RFC 9110 conserva la procedencia de la afirmación: sólo la frontera que representa al origen debe calificar si este contexto puede producir su respuesta autorizada.

Si un intermediario cualquiera pudiera imponer el mismo juicio, el cliente no sabría si estaba corrigiendo una falta de autoridad o obedeciendo una preferencia de encaminamiento ajena.

Alcanzar, autenticar y aceptar no eran sinónimos

El error conceptual consiste en encadenar tres afirmaciones hasta tratarlas como una sola.

La primera es que la conexión alcanza un punto final. La segunda es que ese punto final presentó credenciales aceptables para el nombre solicitado. La tercera es que el despliegue está configurado y dispuesto a responder por ese origen dentro del contexto de esta conexión.

Las dos primeras permiten un intento informado. No fuerzan la tercera. Un certificado puede probar control de la clave privada para varios nombres sin demostrar que todos comparten arrendatario, aplicación, puerto, ruta interna o política operativa.

Tampoco el 421 destruye las pruebas anteriores. La conexión puede seguir siendo correcta para el primer origen. El certificado puede seguir siendo válido para el segundo. La nueva conexión dedicada al segundo puede llegar al servicio apropiado.

El estado conserva esas verdades separadas y rechaza únicamente la arista que las unía de forma incorrecta.

Reintentar significaba corregir la entrega

Después de un 421, el cliente puede reintentar la solicitud por una conexión distinta: una conexión nueva y específica para el origen, por ejemplo, o un servicio alternativo adecuado. RFC 9110 permite hacerlo aunque el método no sea idempotente.

La frase no concede una licencia general para repetir escrituras tras cualquier error. 421 tiene una semántica más estrecha que una desconexión incierta: el emisor ha rechazado producir la respuesta autorizada del origen en el contexto recibido. Otra conexión puede rectificar la selección antes de que el trabajo llegue al servicio correcto.

Aun así, el cliente no está obligado. El cuerpo quizá no pueda reproducirse; las credenciales pueden estar ligadas al canal; una política local puede pedir confirmación; la aplicación puede preferir detener una operación irreversible. MAY conserva esa decisión.

El reintento útil debe cambiar algo. Repetir indefinidamente en la misma conexión coalescida contradice el diagnóstico. El URI, el método y la intención permanecen, pero el establecimiento nuevo puede enviar el SNI del origen objetivo y seleccionar otra ruta interna, incluso si termina en la misma dirección y con el mismo certificado.

La corrección modifica el contexto, no el significado.

No era una redirección sin Location

Una redirección propone otro objetivo. Puede cambiar el host, el camino y la autoridad, y normalmente comunica ese cambio mediante una ubicación. Un 421 no designa un URI sustituto.

Confundirlos puede trasladar credenciales, alterar claves de caché o exponer nombres internos sin que el protocolo lo haya pedido. También puede ocultar una discrepancia operativa: en lugar de corregir el mapa del origen, el servidor hace que el cliente abandone el nombre que quería alcanzar.

421 tampoco equivale a 400 Bad Request; la sintaxis puede ser correcta. No es 403 Forbidden, porque la cuestión principal no es el permiso del usuario sobre el recurso. Y no es un error TLS: la negociación puede haber validado precisamente el certificado que motivó la reutilización.

Nombrar bien el fallo evita que una capa obtenga el poder de redefinir a las demás.

ORIGIN transformó el rechazo en conocimiento previo

El 421 reactivo cuesta tiempo. Primero se envía una solicitud que no será atendida, después se escoge otra conexión. RFC 8336, publicada en marzo de 2018, añadió a HTTP/2 la trama ORIGIN para que el servidor declarara qué orígenes podían usar una conexión.

El conjunto se llama Origin Set. Una vez inicializado, un cliente compatible no debe considerar autorizada la conexión para un origen ausente. Las entradas son orígenes explícitos; no se admiten nombres comodín. Por eso un certificado con amplia cobertura no se convierte silenciosamente en una declaración operativa igual de amplia.

ORIGIN describe una propiedad del enlace y se procesa salto a salto. Los intermediarios no reenvían la trama, y los clientes configurados para usar un proxy ignoran la que éste les envíe. El servidor puede añadir orígenes con tramas posteriores, pero el cliente sigue obligado a validar el certificado. La lista expresa intención de servicio, no crea una credencial.

El aprendizaje continúa después del error: al recibir 421, el cliente que aplica RFC 8336 debe retirar ese origen del Origin Set de esa conexión. Así deja de repetir la misma inferencia en el mismo canal.

La memoria correcta se limita al par origen–conexión. Marcar el origen como inválido en todas partes sería aprender demasiado de un hecho local; olvidarlo sería no aprender nada.

Alt-Svc ofrecía ruta, no autoridad automática

Alt-Svc permite que un origen anuncie otro host, puerto o protocolo como servicio alternativo. RFC 9110 contempla que un cliente elija esa vía al recuperarse de un 421. Sin embargo, el anuncio no elimina la validación ni modifica por sí solo el Origin Set.

Cada señal responde una pregunta distinta. DNS aporta evidencia de alcance. El certificado aporta identidad. Alt-Svc nombra una alternativa. ORIGIN acota las intenciones de una conexión. El despliegue receptor conserva el conocimiento sobre el origen y el contexto que finalmente ha seleccionado.

Si una de esas señales se aceptara como prueba total de las demás, la cadena se autorizaría a sí misma. 421 es el punto en el que el receptor puede negar la combinación sin invalidar cada pieza.

La cooperación funciona porque las afirmaciones siguen siendo estrechas.

HTTP/3 conservó la misma frontera

La especificación actual de HTTP/2, RFC 9113, sustituyó RFC 7540 y mantuvo tanto la reutilización entre orígenes como el 421. RFC 9114 llevó HTTP a QUIC y conservó el mecanismo.

HTTP/3 no utiliza TCP, pero sus conexiones son persistentes y pueden servir autoridades de URI diferentes. Antes de reutilizar una conexión para un origen nuevo, el cliente debe verificar el certificado contra ese origen. Si no es aceptable, la reutilización está prohibida. Si es aceptable, el servidor aún puede responder 421 cuando no quiera que esa conexión se utilice para el origen concreto.

La continuidad separa principio y accidente histórico. 421 nació dentro de HTTP/2, pasó a la semántica común y sobrevivió al cambio de transporte. Su razón de ser aparece siempre que el remitente puede inferir que un canal compartido sirve varios nombres, mientras el receptor conserva información de contexto que la inferencia no alcanza.

QUIC cambió los paquetes. No cambió quién decide si una conexión puede hablar por un origen.

El dato operativo era la relación fallida

Contar respuestas 421 sin identificar la conexión produce una cifra, no una explicación. Cada evento debe conservar el esquema, host y puerto objetivo; el método; la versión HTTP; los identificadores de conexión y flujo; el punto remoto; SNI y ALPN; los nombres del certificado; la respuesta DNS usada para coalescer; el origen de Alt-Svc; el Origin Set; el frontal y el servidor seleccionados; el papel del emisor; y el resultado de la conexión de reintento.

La comparación entre caminos es decisiva. Si sólo falla la conexión compartida y la conexión específica funciona, el contexto es el principal sospechoso. Si ambas reciben 421, quizá el origen esté ausente de toda la configuración. Si el fallo se limita a una región o versión, los anuncios, certificados y servidores pueden haber convergido en momentos distintos.

Un 421 aislado puede ser una corrección sana de una apuesta de rendimiento. La repetición sin convergencia señala el problema duradero.

La eficiencia quedó subordinada a la autoridad

La coalescencia de conexiones reduce negociaciones, estado y latencia. El estándar no pretendió abandonar esos beneficios ni exigir un canal por nombre. Permitió que el cliente decidiera provisionalmente con las pruebas que tenía.

Pero el receptor conservó el veto sobre la información que sólo él conocía: qué SNI, puerto, arrendatario y servidor estaban asociados a esta conexión. Al devolver 421 podía negar una asociación sin adueñarse del URI ni destruir el resto del canal.

Sin esa posibilidad, una conexión establecida para el primer origen podría adquirir poder de hecho sobre todos los nombres de un certificado compartido. La optimización de transporte se convertiría en centralización de servicio.

El registro de códigos de estado HTTP de IANA mantiene 421 como Misdirected Request y remite a RFC 9110. El registro fija un nombre y una referencia interoperables; no demuestra cuántas veces se usa, que todos los clientes reintenten ni que una implantación concreta haya alineado correctamente sus orígenes.

La conexión era real. También lo era el segundo origen. Lo que no existía era el mandato de la primera para representar al segundo. HTTP 421 hizo visible esa ausencia y dejó intacto todo lo demás.