GET
由于您在执行请求时通常不会发送任何其他数据,因此Content-Length
根本不应该发送标头。
仅当您发送message-bodyContent-Length
时才应包含标头,并且相关标头的值始终是该字段的长度,以(OCTETs)字节为单位。
Content-Length entity-header 字段指示发送给接收者的实体主体的大小,以十进制的八进制数表示,或者在 HEAD 方法的情况下,将发送的实体主体的大小具有请求是 GET。
<截图/>
应用程序应该使用这个字段来指示消息体的传输长度,除非这被第4.4节中的规则禁止。
(AFAIK)在执行请求时包含消息体被认为是不好的做法GET
,但是在阅读 HTTP RFC2616时,我没有看到任何说明GET
请求不能包含消息体的内容。
虽然我会假设如果您在消息正文中发送数据并希望在这种情况下对其进行解析和处理,那么今天的大多数 Web 服务器都不会回复您希望他们回复的内容。
HTTP 消息的消息体(如果有)用于携带与请求或响应相关联的实体体。仅当应用了传输编码时,消息主体与实体主体不同,如 Transfer-Encoding 标头字段(第 14.41 节)所示。
message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>
Transfer-Encoding 必须用于指示应用程序应用的任何传输编码,以确保消息的安全和正确传输。Transfer-Encoding 是消息的属性,而不是实体的属性,因此可以由请求/响应链上的任何应用程序添加或删除。(但是,第 3.6 节对何时可以使用某些传输编码进行了限制。)
消息中何时允许消息正文的规则因请求和响应而异。
请求中消息体的存在通过在请求的消息头中包含 Content-Length 或 Transfer-Encoding 头字段来表示。
如果请求方法的规范(第 5.1.1 节)不允许在请求中发送实体主体,则消息主体不得包含在请求中。
服务器应该在任何请求上读取并转发消息体;如果请求方法不包括为实体主体定义的语义,则在处理请求时应该忽略消息主体。