此外,未完全实施的扩散方式
自称为“ HTTP / 1.0”的应用程序需要一个
协议版本更改,以便两个通讯应用程序
以确定彼此的真正能力。
答案 0 :(得分:2)
从RFC:
HTTP自1990年以来就被万维网全球信息倡议所使用。HTTP的第一个版本称为HTTP / 0.9,是用于通过Internet传输原始数据的简单协议。
措辞:
在对HTTP进行标准化之前,实现方式存在差异,这意味着它们不能始终彼此正确通信(例如,某些Web浏览器无法与某些Web服务器一起使用)。 RFC文章使用HTTP/0.9
引用了这些标准化前的实现。
RFC 1945定义的HTTP / 1.0,通过允许消息采用类似于MIME的消息格式来改进了协议,其中包含有关所传输数据的元信息以及请求/响应语义上的修饰符。但是,HTTP / 1.0没有充分考虑分层代理,缓存,对持久连接的需求以及虚拟主机的影响。此外,自称“ HTTP / 1.0”的未完全实现的应用程序的激增,必须更改协议版本,以便两个通信的应用程序确定彼此的真正功能。
措辞:
将HTTP标准化为HTTP/1.0
后,无疑可以解决互操作性和兼容性问题,但是该协议的版本1.0
只是假设所有HTTP软件都可以将其用于现有应用程序,但是现在HTTP/1.0
已经使用了一段时间,HTTP协议规范的维护者发现他们需要扩展HTTP以支持这些用例(例如代理,缓存,持久连接,虚拟主机),尽管可以使用HTTP/1.0
中的内置扩展机制来完成这些操作,但他们认为有必要将版本号增加到HTTP/1.1
,以防止仅假设远程主机就可以实现是否支持某个功能。
一个很好的例子是Host
中的HTTP/1.1
标头,它允许从单个IP地址和端口号提供服务的Web服务器根据Host
为不同的网站提供服务标头(与之前HTTP/1.1
一样,网络服务器每个IP地址只能服务一个网站,这是一个问题)。 HTTP/1.0
确实允许客户端和服务器添加自己的自定义标头,例如Host
,但是客户端或服务器无法知道另一端实际上支持Host
标头。但是在HTTP/1.1
中,Host
标头是以前添加到规范中的,因此,如果客户端和服务器都声明他们使用HTTP/1.1
,则另一端知道他们将识别{{1} }标头并正确处理。
因此,在Host
天中,具有自定义标题,如果浏览器请求HTTP/1.0
是从共享Web主机提供的服务,这就是它的播放方式:< / p>
www.example.com
如您所见,浏览器即使要求Browser (to DNS server): "Please give me the IP address for 'www.example.com'"
DNS Server (to browser): "www.example.com is 198.51.100.7"
Browser (to 198.51.100.7): "Hello, I speak HTTP/1.0, please send me index.html for Host: www.example.com
Server (to browser): "I also speak HTTP/1.0, here is index.html for 'not-actually-example.com'"
也获得not-actually-example.com
,因为Web服务器使用的www.example.com
无法识别HTTP/1.0
标头,即使网络浏览器正在发送Host
标头(作为扩展名/实验标头)。 浏览器软件无法知道用户是否想要Host
。
答案 1 :(得分:1)
用人的话来说,他们的意思是:这么多人说他们做了HTTP 1.0而没有做,没有人知道有人说HTTP 1.0以后是否真的是HTTP 1.0。
要摆脱困境,他们选择了一个新号码。