Summary

  • Early HTTP could ask for / over a TCP connection, but the destination address did not preserve which DNS name the user had chosen.
  • HTTP/1.1 required Host so a server could place one path inside the correct named resource space and host several sites on one IP address.
  • Because authority could appear in both an absolute request-target and Host, specifications defined precedence, proxy rewriting and rejection of missing, duplicate or invalid values.

The server received an address and a slash

RFC 1945 recorded HTTP/1.0 as it was commonly used. A client resolved a name, opened TCP to an address and sent a request whose target often contained only a path. When one address corresponded to one Web server, GET / was sufficient in practice: the connection itself selected the only available root.

That convenience did not scale. DNS might map several names to the same address, but the server did not receive the client's DNS question. TCP delivered a connection to an address and port, not the original label typed or followed by the user. Once two sites shared that endpoint, / described a path without identifying the namespace that owned it.

HTTP/1.1 put authority back into the message

In January 1997, RFC 2068 made Host a required HTTP/1.1 request field. A direct origin request normally carried only path and query in the request line, while Host carried the URI's network location. The exact resource came from both pieces.

The rule was deliberately strict. Every Internet HTTP/1.1 request had to include Host, and a server had to return 400 when it was absent. The appendix called this one of the specification's most important changes. Its stated purpose was to support several Web sites on one IP address and recover addresses allocated merely to distinguish special-purpose domain names.

Host did not make the name true. It made the client's intended authority explicit enough for routing. An origin still had to decide whether that name was valid on the server.

One request could carry the name twice

Direct requests usually use origin-form: a path such as /pub/index. Requests to a proxy can use absolute-form, where the request-target already contains scheme, host and path. If the absolute URI says one host while the Host field says another, blindly honouring both gives different recipients two possible targets.

RFC 2068 therefore made the absolute request-target authoritative in that case. RFC 7230 later required a proxy receiving absolute-form to ignore the received Host and replace it with the authority from the target before forwarding. The intermediary transforms two representations into one decision.

The same logic explains hard rejection. An HTTP/1.1 server must answer 400 for a missing Host, more than one Host field, or an invalid value. Choosing the first, last or most convenient copy would let proxy, cache and origin disagree on the request's destination.

A complete target is reconstructed, not merely read

RFC 7230 called the result the effective request URI. Depending on the request form, a recipient combines server configuration, connection security context, request-target and Host. The path is only one component; the authority determines which resource space interprets it.

That reconstruction distributes power. The user agent declares its target. A proxy normalises the form it forwards. The origin validates whether it serves the authority and chooses a virtual host. A cache must key the response under the same target that routing used. A redirect generator must not invent an external name from unvalidated input.

RFC 7230 specifically warns against using an unverified Host value for internal redirection or as a shared-cache key. The problem is not that Host is optional or decorative. It is precisely that Host can change where the request goes while still being supplied by the requester.

The field survived by becoming an invariant

Current HTTP/1.1 syntax in RFC 9112 keeps the contract: one valid Host field is mandatory, including when the target authority is empty. The rules no longer assume that a friendly heuristic can repair an ambiguous request.

HTTP/2 changed representation, not the need. RFC 9113 carries target authority in :authority. When an intermediary constructs an HTTP/1.1 request, it must use that value for Host and replace an existing Host unless it also changes the request target. Protocol translation must preserve one authority, not forward competing claims.

The historical change was small in syntax and large in governance. One mandatory name loosened the one-address-one-site assumption, but every intermediary then became responsible for keeping that name singular and consistent.

Sources and limits

The closed set is RFC 1945, RFC 2068, RFC 7230, RFC 9112 and RFC 9113. It establishes protocol rules and motivation, not current virtual-host counts, addresses saved, browser share, product defaults or incident frequency. Host expresses request authority; it does not authenticate DNS ownership, TLS identity or the sender.