HTTP 请求行和状态行都有 3 个组成部分：
Request-Line= Method SP Request-URI SP HTTP-Version CRLF
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
状态行（服务器响应）很好：
我不明白的是为什么请求行如此不同：
为什么它不遵循与状态行相同（干净）的模式？
Request-Line= HTTP-Version SP Method SP Request-URI CRLF
这样，Request-URI 可以是任何文本字符（CR/LF 除外）
所以它看起来像这样：
HTTP/1.1 GET /user/with space
...
HTTP/1.1 404 NOT FOUND
...
看：
它可能来自HTTP/0.9，早期的协议版本。
请求部分是：
GET http://www.example.com/foo.html\r\n
响应部分是响应正文（没有标题），因此直接从<html>例如 html 响应开始。
请求行是：
METHOD OSP Absolute-Request-URL CRLF
重要的一点是没有协议版本，也没有协议部分。无论是在响应还是请求中。
当 HTTP/1.0 创建时，隐含的需求仍然支持 HTTP/0.9 请求和响应。一些服务器今天仍在做的事情。
在响应端，添加了所有响应标头部分（例如说明响应的 mime 类型！），并且第一行是按照从响应的协议版本开始的好主意构建的。
在请求端，协议版本被添加为可选添加，因此您仍然可以决定发出 HTTP/0.9 请求或新版本，最重要的是，HTTP/0.9 服务器可能仍然可以理解您的查询（并忽略SP PROTOCOL添加（甚至在请求中添加可选标头）。今天，如果您忘记了请求的协议部分，HTTP/0.9 兼容服务器将仅解析请求的第一行并忽略额外的标头。
这些是等效的查询（但第一个查询位于 http 0.9 中，并且在响应中不会得到任何标头）：
# HTTP 0.9:
GET http://www.example.com/foo.html\r\n
# HTTP/1.0 version:
GET http://www.example.com/foo.html HTTP/1.0\r\n
\r\n
# or
GET /foo.html HTTP/1.0\r\n
Host: www.example.com\r\n
\r\n
#or
GET http://www.example.com/foo.html HTTP/1.0\r\n
Host: www.foo.com\r\n
\r\n
我认为他们一直在考虑解析器中所需的代码更新，并且在第一行末尾添加协议更容易实现。也许旧的解析器仍然可以向 HTTP/1.0 查询发送 0.9 响应（这很糟糕，但很容易编写）。
也许只是在现有线路上添加一些东西似乎比在现有协议的线路上添加前缀更像是一种改进。
也许你现在应该已经足够大了，可以评论 RFC 并告诉他们你的方式会更优雅（这是正确的）:-)