Summary

  • 1991 年万维网早期实现的 HTTP 描述为：客户端发出一条 GET 请求，服务器返回 HTML 文档，并通过关闭连接标示文档结束。
  • 这个精简交换没有状态行和头字段。同期设计说明指出，错误也以文档形式返回，除非读懂文字，否则无法与成功响应区分。
  • 后来的 HTTP 加入版本、头字段和状态码，同时保留简单格式以兼容旧实现；这条兼容路径并不能说明 HTTP/0.9 的普及规模。

页面本身就是完整响应

在 1991 年的万维网实现说明中，客户端先连接服务器；地址没有指定端口时，默认使用 80。随后客户端发送一行 GET 和文档标识符。服务器返回 HTML 字节流，发完文档便关闭连接。页面前面没有独立的状态行，后面也没有头字段区块：客户端收到的第一个字节就属于文档内容。

Tim Berners-Lee 留下的实现说明并没有描述一个包在网页外面的 HTTP 信封。它直接把响应称作 HTML 消息，说明连接关闭会终止传输；服务器也可以用 HTML 提供人能读懂的错误文字。说明还明确指出代价：除非查看文本本身，否则没有办法区分错误响应和正常响应。浏览器能把内容显示出来，但线路格式没有可供程序读取的“未找到”、重定向或服务器错误代码。

1992 年 6 月的概要把这种取舍说得很清楚。浏览器只发送一个命令 GET，后面接文档标识符；若指向命名索引，还可以附加关键词。服务器不保存与浏览器有关的状态。返回内容可以是 HTML 或纯文本，也可以包含菜单、搜索命中列表或文档。简单是它的优点：服务器传出的只有带标记的文本。但概要也指出，没有词法边界把 HTTP 信息、文档内容和文档类型分开。错误消息只是另一份文档，读者可能略过。

这种模糊属于消息格式本身，并不证明早期服务器经常故障，也不意味着人读不懂错误页。人可以判断正文含义，程序却没有状态字段可查。连接关闭既标记正常的文档末尾，也会结束一次被中断的交换。客户端知道字节流停了，却不知道它为什么停。

早期 HTTP 也不是只能取静态页面。ISINDEX 标记可以提示浏览器把关键词附加到文档标识符来构造查询，服务器则能返回 HTML 命中列表。Berners-Lee 关于“为什么需要新协议”的说明还把索引搜索、自动格式协商、把客户端引向另一台服务器列为信息访问协议需要的能力。这些是更广泛的设计目标，不等于一行式的简单交换已经提供全部功能。

从文档扩展到可解释的响应

1992 年 12 月公开的 www-talk 邮件展示了一种扩展提案。Berners-Lee 主张新服务器继续识别 GET <url>，客户端则可以在同一行加入版本标记，随后发送 From、Accept 和 Accept-Encoding 等头字段。他举例的响应包含版本、响应字段、MIME 内容类型和支持的方法。这是讨论中的提案，不是最终部署格式的抓包记录；但它说明了设计关注点如何变化：响应需要描述自身，而不只是交付内容。

1996 年发布的 Informational RFC 1945 后来同时描述了两种形式。简单请求仍是 GET 加 URI，不带头字段；简单响应仍只有实体正文，并在服务器关闭连接时结束。完整响应则以状态行开头，还可带响应头和实体头。RFC 特别提醒，简单请求无法让服务器标识返回内容的媒体类型。保留旧格式可识别，使后来的系统能照顾较早的客户端和服务器，又不必声称两者发的是同一种消息。

时间顺序也很重要。RFC 对早期简单格式的追溯定义有助于理解兼容性，却不能证明 1991 年已单独批准一项 HTTP/0.9 标准。Berners-Lee 后来回忆，首个 Web 服务器和客户端软件——包括 Nicola Pellow 的行模式浏览器——在 1991 年夏季先后发布给高能物理、超文本和 NeXT 社群。他还说，URI、HTML 和 HTTP 规范被放在首台服务器上，以推动讨论与采用。这些材料提供实验背景，但没有统计不同消息格式的部署数量。

把文档直接作为响应，让系统容易理解：请求一个资源，收回浏览器能显示的内容。当客户端必须把响应当成协议事件处理时，限制就出现了。没有状态行，HTML 错误页和普通页面占据同一个位置。后来的完整 HTTP 消息把结果、元数据和表示分开，而简单格式仍留作可识别的兼容路径。

来源