Resumo

  • Em HTTP/1.0, o servidor podia receber uma conexão e apenas um caminho, sem o nome DNS que o cliente havia escolhido.
  • HTTP/1.1 exigiu Host para colocar o caminho no espaço de recursos correto e permitir muitos sites no mesmo endereço IP.
  • Como uma URI absoluta também contém autoridade, os padrões definiram precedência, reescrita por proxy e rejeição de Host ausente, duplicado ou inválido.

Um endereço e uma barra não bastavam

A RFC 1945 registrou o uso comum de HTTP/1.0. O cliente resolvia um nome, abria TCP e enviava frequentemente só um caminho. Com um site por endereço, GET / parecia completo: a conexão escolhia a única raiz.

DNS podia apontar vários nomes para a mesma IP, mas a pergunta DNS original não acompanhava a conexão. O servidor recebia endereço e porta, não o rótulo usado pela pessoa. Em um endpoint compartilhado, / já não identificava um único catálogo.

Host devolveu a autoridade à mensagem

A RFC 2068, de janeiro de 1997, exigiu Host em pedidos HTTP/1.1. Na forma direta, a linha leva path e query; Host leva a localização de rede. O recurso exato depende dos dois.

Ausência de Host passou a exigir 400. A especificação apresentou a regra como essencial para múltiplos sites por IP e para recuperar endereços usados apenas para separar nomes Web.

Host declara intenção, não propriedade. O origin ainda precisa validar se atende àquela autoridade.

Duas autoridades pediam uma vencedora

Pedido direto costuma usar origin-form. Um proxy pode receber absolute-form, com esquema, host e caminho. Se essa URI diz A e Host diz B, a mensagem oferece dois destinos.

RFC 2068 priorizou a URI absoluta. A RFC 7230 mandou o proxy substituir Host pela autoridade do request-target. A contradição deve terminar no intermediário.

Pedido sem Host, com múltiplas linhas ou valor inválido recebe 400. Escolher primeira ou última cópia deixaria proxy, cache e origin tomar decisões distintas.

O alvo efetivo é reconstruído

RFC 7230 chama o resultado de URI efetiva. Configuração, contexto da conexão, formato do target e Host participam em ordem definida. Um path só ganha sentido dentro de uma autoridade.

O user agent declara, o proxy normaliza e o origin valida e escolhe o virtual host. Cache e redirecionamento precisam usar a mesma autoridade. A RFC alerta contra Host não verificado em roteamento interno ou chave de cache compartilhada.

O risco existe porque o campo tem poder real sobre o destino, embora seja fornecido por quem faz a solicitação.

O invariante sobreviveu ao formato

A RFC 9112 mantém um Host único e válido no HTTP/1.1. Não há heurística legítima para resolver duas identidades.

HTTP/2 usa :authority. A RFC 9113 exige que o intermediário derive Host desse valor ao criar HTTP/1.1 e substitua qualquer Host anterior, salvo mudança conjunta do target. Tradução preserva uma autoridade, não duas versões.

Host separou site de endereço, mas distribuiu pela cadeia a responsabilidade de manter o nome singular e coerente.

Fontes e limites

O conjunto fechado contém RFC 1945, RFC 2068, RFC 7230, RFC 9112 e RFC 9113. Ele estabelece regras e motivação, não quantidade atual de sites, IPs poupadas, defaults ou incidentes. Host não autentica DNS, TLS nem remetente.