编辑：后来，似乎有些浏览器将术语"响应标头"与"响应消息（无响应主体）"相混淆。这就是这个问题出错的地方。浏览器只是不正确。同时，我回答了自己的问题。
在Firefox中，您可以通过" Firefox开发人员工具">" Network"检查"原始标头"。
原始响应标头的示例：
Date: Thu, 23 Nov 2017 12:43:21 GMT
Server: Apache/2.4.17 (Unix) OpenSSL/1.0.1e-fips PHP/5.6.16
Connection: Keep-Alive
Keep-Alive: timeout=1, max=100
Cache-Control: max-age=9, public
Vary: User-Agent
但我想念（例如）：" http/1.1 304未修改"。Firefox显示在其他地方" 304未修改"，但不是原始的。
因此，他们让我认为我的响应标题是原始形式，但实际上它只是响应标题的一部分，不包括状态代码。这确实使人们感到困惑。我认为，在那个地方也添加"状态代码"将更有意义。现在这不是真正合乎逻辑的。
这是一个错误还是我必须如何看？
同时我可以回答自己的问题。
此刻，一些浏览器是使用错误的术语。他们令人困惑的是"回复标题"。＆quot"响应消息（无消息主体）"。这就是为什么我在问这个问题时感到困惑，这就是问题的原因。
请参阅：https：//www.rfc-editor.org/rfc/rfc7230#page-8（2.1。Client/client/server Messaging）
服务器通过发送一个或多个http来响应客户端的请求响应消息，每个都以一个状态行开始，其中包括协议版本，成功或错误代码以及文本原因短语（第3.1.2节），可能是包含的标头字段服务器信息，资源元数据和表示元数据（第3.2节），一条用于指示标题末端的空行部分，最后是包含有效负载主体的消息主体（如果任何，第3.3节）。
换句话说。
响应消息：
Status line (ending with CRLF, so 2 extra Bytes)
Header field 1, in case of (ending with CRLF, so 2 extra Bytes)
Header field 2, in case of (ending with CRLF, so 2 extra Bytes)
Header field 3, et cetera (ending with CRLF, so 2 extra Bytes)
Empty line to indicate the end of the header section (CRLF, so 2 extra Bytes)
Message body / Response body, if any
响应标头/响应标头字段：
Header field 1 in case of (ending with CRLF, so 2 extra Bytes)
Header field 2 in case of (ending with CRLF, so 2 extra Bytes)
Header field 3 et cetera (ending with CRLF, so 2 extra Bytes)
正式地，状态线不是"依据"标题的一部分，而是"响应消息"的一部分。
firefox 例如，显示"依据标题"的大小。在：" Firefox开发人员工具"＆gt;"网络"＆gt;单击行＆gt;标题选项卡。
此大小还包括I.A的大小。状态线。原始响应标头的大小必须对应于此大小，但目前不是这样。因此，否则他们需要更改大小，否则他们必须额外包括"状态线"。 "空线"在（RAW）响应标题中，他们必须给它另一个名称（例如：响应消息 - 消息正文）。
chrome 也做错了。例如，请参见：https：//developers.google.com/web/tools/chrome-devtools/network-performance/reference#requests
他们在那里说：
大小。服务器提供的响应标头和响应主体的组合大小。
，但实际上它们的意思是不同的（也是根据实践中大小的值）。他们实际上是指：
大小。响应消息的组合大小，没有消息主体（而不是响应标头）以及服务器提供的响应主体。
实际上与其他单词：
大小。服务器传递的响应消息的组合大小。
所以这就是我的起源问题的来源。显然，这对于浏览器而言，这是一个困难的主题，因为我在2个浏览器中对其进行了测试，并且两者都犯了错误。
因此，如果人们认为状态线是响应标题的一部分，那并不奇怪。