http - HTTP 1.1 GET 中强制性 'Host' 子句的原因

Question

上周，我在计算机网络课上大惊小怪，因为HTTP 1.1 GET 的 header 中需要一个强制性的Host 子句> 消息。

提供给我的原因，无论是写在网上还是被同学冲我大喊大叫，总是一样的:需要支持虚拟主机。但是，我会尽量说清楚，这似乎没有意义。

我明白，为了允许两个域托管在一​​台机器上(因此，共享相同的 IP 地址)，必须存在一种区分两个域名的方法。

我不明白的是，为什么没有 Host 子句(HTTP 1.0 样式)无法通过使用绝对 URL(例如 GET http://www.example.org/index.html)而不是相对的(例如 GET/index.html )。当 HTTP 消息到达服务器时，它(服务器)会将消息重定向到适当的主机，而不是通过查看 Host 子句，而是通过查看在消息的请求行中出现的URL 中的主机名。

如果你们中的任何一位铁杆黑客能帮助我理解我到底错过了什么，我将不胜感激。

Answer 1

这在 this thread 中讨论过:

modest suggestions for HTTP/2.0 with their rationale.

1. Add a header to the client request that indicates the hostname and port of the URL which the client is accessing.

Rationale: One of the most requested features from commercial server maintainers is the ability to run a single server on a single port and have it respond with different top level pages depending on the hostname in the URL.

需要一个绝对请求 URI(因为客户端无法事先知道服务器是否拥有一个或多个站点)是 suggested :

Re the first proposal, to incorporate the hostname somewhere. This would be cleanest put into the URL itself :-

GET http://hostname/fred http/2.0

This is the syntax for proxy redirects.

到哪个this提出论点:

Since there will be a mix of clients, some supporting host name reporting and some not, it just doesn't matter how this info gets to the server. Since it doesn't matter, the easier to implement solution is a new HTTP request header field. It allows all clients and servers to operate as they do now with NO code changes. Clients and servers that actually need host name information can have tiny mods made to send the extra header field containing the URL and process it.

[...]

All I'm suggesting is that there is a better way to implement the delivery of host name info to the server that doesn't involve hacking the request syntax and can be backwards compatible with ALL clients and servers.

请随意继续阅读以自己发现最终决定。但请注意，那里很容易迷路。