Resumen

  • En HTTP/1.0, una conexión llegaba a una dirección y la petición podía contener sólo una ruta; el servidor no recibía necesariamente el nombre DNS original.
  • HTTP/1.1 exigió Host para asociar esa ruta con el espacio de recursos correcto y alojar varios nombres en una dirección IP.
  • Las URI absolutas podían contener otra autoridad, así que las normas fijaron precedencia, normalización por proxies y rechazo de Host ausente, duplicado o inválido.

Una barra sin nombre

La RFC 1945 documentó el uso habitual de HTTP/1.0. El cliente resolvía un nombre, abría TCP hacia una dirección y enviaba una ruta. Si esa dirección servía un único sitio, GET / no parecía ambiguo: el destino de la conexión elegía la raíz.

DNS podía llevar muchos nombres a la misma IP, pero TCP no entregaba al servidor la consulta que produjo esa dirección. Conservaba dirección y puerto, no la etiqueta que el usuario había seleccionado. En un endpoint compartido, la misma barra podía pertenecer a varios sitios.

La autoridad entró en la petición

La RFC 2068 hizo obligatorio Host en enero de 1997. Una petición directa mantenía ruta y query en la línea inicial; el campo añadía la localización de red. Sólo ambas partes identificaban el recurso.

El servidor debía responder 400 si faltaba Host. La especificación presentó la medida como esencial para operar varios sitios por IP y recuperar direcciones dedicadas únicamente a distinguir nombres Web.

Host declaraba intención, no propiedad. La autoridad seguía siendo entrada del cliente y el origen debía comprobar que el nombre pertenecía a su configuración.

Dos autoridades no podían viajar intactas

La forma habitual hacia un origen sólo incluye la ruta. La forma absoluta, usada con proxies, ya contiene esquema, host y ruta. Si la URI absoluta nombra un sitio y Host otro, distintos receptores pueden escoger destinos distintos.

RFC 2068 dio prioridad a la URI absoluta. La RFC 7230 ordenó al proxy sustituir Host por la autoridad de esa URI. La traducción debe eliminar la contradicción, no transportarla.

También se rechazan peticiones sin Host, con más de una línea Host o con valor inválido. Elegir la primera o la última copia convertiría una diferencia de parser en una diferencia de destino.

El objetivo efectivo se reconstruye

RFC 7230 llamó URI efectiva al resultado de combinar configuración, contexto de conexión, forma del request-target y Host. La ruta no es un identificador autosuficiente; necesita una autoridad que defina el espacio donde se interpreta.

El agente declara, el proxy normaliza y el origen valida y selecciona el sitio virtual. Cachés y generadores de redirecciones deben adoptar la misma decisión. RFC 7230 advierte sobre usar un Host no verificado para redirigir hacia servidores internos o construir claves de caché compartida.

La superficie de riesgo existe porque Host sí controla el enrutamiento. Una cabecera remitida por quien hace la petición no puede convertirse por sí sola en prueba de identidad.

La autoridad cambió de sintaxis, no de función

La RFC 9112 conserva un Host único y válido como requisito de HTTP/1.1. La ambigüedad debe terminar en error.

HTTP/2 usa :authority. La RFC 9113 exige que un intermediario use ese valor al crear Host para HTTP/1.1 y reemplace cualquier copia previa, salvo que también cambie el objetivo. Atravesar protocolos no autoriza dos identidades paralelas.

Host separó sitio y dirección. Esa libertad ahorró identidad de transporte, pero hizo que cada salto asumiera responsabilidad por una identidad aplicativa singular.

Fuentes y límites

El conjunto cerrado reúne RFC 1945, RFC 2068, RFC 7230, RFC 9112 y RFC 9113. Establece reglas y motivación, no cifras actuales de sitios, IP ahorradas, ajustes de productos o frecuencia de incidentes. Host no autentica DNS, TLS ni al emisor.