不带Content-Length或Transfer-encoding的GET请求的HTTP响应中会发生什么? [英] What happens in HTTP response to a GET request without Content-Length or Transfer-encoding?

问题描述

如果对GET请求的响应没有Content-Length或Transfer-encoding:分块字段，会发生什么?客户端如何知道消息何时结束?

If a response to a GET request doesn't have the Content-Length or Transfer-encoding: chunked field, what happens? How does the client know when the message ends?

推荐答案

RFC 7230第3.3.3 节包含一个很好的条件清单，用于查找邮件正文大小.从本质上说，答案取决于状态码是什么.相关条件是#1和#7.

RFC 7230 section 3.3.3 contains a nice checklist of conditions for finding the message body size. Essentially it says the answer depends on what the status code is. The relevant conditions being #1 and #7.

"1.任何响应...带有1xx(信息性)，204(无内容)或304(未修改)状态代码始终以标头字段，无论邮件，因此不能包含邮件正文."

"1. Any response ... with a 1xx (Informational), 204 (No Content), or 304 (Not Modified) status code is always terminated by the first empty line after the header fields, regardless of the header fields present in the message, and thus cannot contain a message body."

"7.否则，这是没有声明消息的响应消息正文长度，因此消息正文长度由服务器关闭服务器之前收到的八位字节数连接."

"7. Otherwise, this is a response message without a declared message body length, so the message body length is determined by the number of octets received prior to the server closing the connection."

值得一提的是，该消息可能会在正文部分结束后继续出现. RFC 7230第4.4节定义了 Trailers 功能，其中有效负载之后可以跟第二组mime标头.如果存在这些消息，则消息将在其结束处结束.

Its also worth knowing that the message may continue after the end of the body portion. RFC 7230 section 4.4 defines a Trailers feature where the payload may be followed by a second set of mime headers. If those exist the message ends where they do.

这篇关于不带Content-Length或Transfer-encoding的GET请求的HTTP响应中会发生什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！