HTTP规范中关于请求/响应中的message-body和entity-body
请求
响应
并不是所有的请求响应消息中都包含内容：message body或者entity body。
大多数请求消息中不包含消息体。
在有些请求的响应中不包含响应内容。
比如，如果在请求消息中包含If-Modified-Since头字段，如：If-Modified-Since: Sat, 29 Oct 2014 19:43:31 GMT，如果被请求的资源在这个指定的时间之后都没有被修改过，将返回一个304 (not modified)，响应消息中不包含消息体部分，被请求的资源内容不会传输给客户端。
即便是在响应消息中，也可能不包含响应内容。
请求响应消息中是否包含消息体跟请求方式，如GET,POST等，请求响应中的header头部字段，是否有缓存等等。当然也看是否有数据需要进行传输。
message-body
message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>
从这里的定义来看，message-body和entity-body基本上没什么区别。
entity-body
message-body和entity-body的区别
message-body和entity-body的区别在于消息中是否应用了transfer-coding，即在响应或请求消息中是否包含Transfer-Encoding通用头部。
来自https://tools.ietf.org/html/rfc2616的引用：
写道
The message-body (if any) of an HTTP message is used to carry the
entity-body associated with the request or response. The message-body
differs from the entity-body only when a transfer-coding has been
applied, as indicated by the Transfer-Encoding header field (section
14.41).
message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>
Transfer-Encoding MUST be used to indicate any transfer-codings
applied by an application to ensure safe and proper transfer of the
message. Transfer-Encoding is a property of the message, not of the
entity, and thus MAY be added or removed by any application along the
request/response chain. (However, section 3.6 places restrictions on
when certain transfer-codings may be used.)
The rules for when a message-body is allowed in a message differ for
requests and responses.
The presence of a message-body in a request is signaled by the
inclusion of a Content-Length or Transfer-Encoding header field in
the request's message-headers. A message-body MUST NOT be included in
a request if the specification of the request method (section 5.1.1)
does not allow sending an entity-body in requests. A server SHOULD
read and forward a message-body on any request; if the request method
does not include defined semantics for an entity-body, then the
message-body SHOULD be ignored when handling the request.
For response messages, whether or not a message-body is included with
a message is dependent on both the request method and the response
status code (section 6.1.1). All responses to the HEAD request method
MUST NOT include a message-body, even though the presence of entity-
header fields might lead one to believe they do. All 1xx
(informational), 204 (no content), and 304 (not modified) responses
MUST NOT include a message-body. All other responses do include a
message-body, although it MAY be of zero length.
entity-body associated with the request or response. The message-body
differs from the entity-body only when a transfer-coding has been
applied, as indicated by the Transfer-Encoding header field (section
14.41).
message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>
Transfer-Encoding MUST be used to indicate any transfer-codings
applied by an application to ensure safe and proper transfer of the
message. Transfer-Encoding is a property of the message, not of the
entity, and thus MAY be added or removed by any application along the
request/response chain. (However, section 3.6 places restrictions on
when certain transfer-codings may be used.)
The rules for when a message-body is allowed in a message differ for
requests and responses.
The presence of a message-body in a request is signaled by the
inclusion of a Content-Length or Transfer-Encoding header field in
the request's message-headers. A message-body MUST NOT be included in
a request if the specification of the request method (section 5.1.1)
does not allow sending an entity-body in requests. A server SHOULD
read and forward a message-body on any request; if the request method
does not include defined semantics for an entity-body, then the
message-body SHOULD be ignored when handling the request.
For response messages, whether or not a message-body is included with
a message is dependent on both the request method and the response
status code (section 6.1.1). All responses to the HEAD request method
MUST NOT include a message-body, even though the presence of entity-
header fields might lead one to believe they do. All 1xx
(informational), 204 (no content), and 304 (not modified) responses
MUST NOT include a message-body. All other responses do include a
message-body, although it MAY be of zero length.
相关推荐
本篇文章主要会介绍nginx中请求的接收流程，包括请求头的解析和请求体的读取流程。 首先介绍一下rfc2616中定义的http请求基本格式： Request = Request-Line *(( general-header | request-header | entity-...
它是一种通用的，无状态（stateless）的协议，除了应用于超文本传输外，它也 可以应用于诸如名称服务器和分布对象管理系统之类的系统，这可以通过扩展它的请求方法，错误代码和报头[47]来实现。HTTP的一个特点是数据...
3.7.1规范化和文本缺省 27 3.7.2多部分类型（Multipart type） 28 3.8 产品标记 （product Tokens） 29 3.9 质量值（Quality Values） 29 3.10 语言标签 （Language Tags） 30 3.11 实体标签 30 3.12 范围单位...
压缩包中含有多个文档，从了解httpclient到应用。 httpClient 1httpClint 1.1简介 HttpClient是Apache Jakarta Common下的子项目，用来提供高效的、最新的、功能丰富的支持HTTP协议的客户端编程工具包，并且它支持...
forward是服务器请求资源，服务器直接访问目标地址的URL，把那个URL的响应内容读取过来，然后把这些内容再发给浏览器，浏览器根本不知道服务器发送的内容是从哪儿来的，所以它的地址栏中还是原来的地址。 redirect...
forward是服务器请求资源，服务器直接访问目标地址的URL，把那个URL的响应内容读取过来，然后把这些内容再发给浏览器，浏览器根本不知道服务器发送的内容是从哪儿来的，所以它的地址栏中还是原来的地址。...
addCookie(Cookie) - Method in class javax.servlet.http.HttpServletResponseWrapper The default behavior of this method is to call addCookie(Cookie cookie) on the wrapped response object. addCookie...
6.4 Message Body Header Fields 158 6.4.1 Allow 158 6.4.2 Content-Encoding 158 6.4.3 Content-Disposition 158 6.4.4 Content-Language 158 6.4.5 Content-Length 159 6.4.6 Content-Type 159 6.4.7 Expires 160...
EntityResponse entityResponse = api.basic( apiKey, Ruc.of("20600567013") ).execute().body(); System.out.println("entity: " + entityResponse);Respuesta { "success": true, "message": "Ruc encontrado", ...
4.3 Message Body ................................................32 4.4 Message Length ..............................................33 4.5 General Header Fields ......................................
7.4.2 Message Body Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.5 Framing SIP Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8 ...