Question

HTTP请求行和状态行都有3个组成部分：

Request-Line= Method       SP Request-URI SP HTTP-Version  CRLF
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

状态行（服务器响应）很好：

它以HTTP版本（类似于任何协议）开头，因此解码器可以根据该第一个字段来调整其解析
后跟一些协议定义的值（状态代码），即一个单词，不需要任何SP / CR / LF字符
以任何TEXT字符（CR / LF除外）结尾作为原因短语。

我无法理解的是为什么请求行如此不同：

HTTP版本位于结尾
必须对Request-URI进行转义，以避免带有SP / CR / LF字符（此处使用著名的％20）

为什么它不遵循与状态行相同（干净）的模式？

Request-Line= HTTP-Version SP Method     SP Request-URI CRLF

这样，Request-URI可以是任何TEXT字符（CR / LF除外）

所以它看起来像这样：

HTTP/1.1 GET /user/with space
...

HTTP/1.1 404 NOT FOUND
...

请参阅：

Answer 1

它可能来自早期的协议版本 HTTP/0.9。

请求部分是：

GET http://www.example.com/foo.html\r\n

响应部分是响应正文（没有标题），例如直接以 <html> 开头的 html 响应。

请求行是：

METHOD OSP Absolute-Request-URL CRLF

为 OSP 提供许多可选空间，例如制表符或换页符
位置部分也有主机部分（今天协议仍然支持）

重点是没有协议版本，也没有协议部分。在响应和请求中。

当创建 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 并告诉他们你的方式会更优雅（这是正确的）:-)

为什么HTTP状态行与请求行不同

1 个答案: