Ignore:
Timestamp:
Feb 20, 2012, 6:12:49 PM (8 years ago)
Author:
fielding@…
Message:

For consistency and readability, do not hyphenate "message body"
unless we are referring to the message-body ABNF rule.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r1540 r1544  
    12061206      <p id="rfc.section.3.p.1">All HTTP/1.1 messages consist of a start-line followed by a sequence of octets in a format similar to the Internet Message
    12071207         Format <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a>: zero or more header fields (collectively referred to as the "headers" or the "header section"), an empty line indicating
    1208          the end of the header section, and an optional message-body.
     1208         the end of the header section, and an optional message body.
    12091209      </p>
    12101210      <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.25"></span>  <a href="#http.message" class="smpl">HTTP-message</a>    = <a href="#http.message" class="smpl">start-line</a>
     
    12131213                    [ <a href="#message.body" class="smpl">message-body</a> ]
    12141214</pre><p id="rfc.section.3.p.3">The normal procedure for parsing an HTTP message is to read the start-line into a structure, read each header field into a
    1215          hash table by field name until the empty line, and then use the parsed data to determine if a message-body is expected. If
    1216          a message-body has been indicated, then it is read as a stream until an amount of octets equal to the message-body length
     1215         hash table by field name until the empty line, and then use the parsed data to determine if a message body is expected. If
     1216         a message body has been indicated, then it is read as a stream until an amount of octets equal to the message body length
    12171217         is read or the connection is closed.
    12181218      </p>
     
    12291229      <p id="rfc.section.3.1.p.1">An HTTP message can either be a request from client to server or a response from server to client. Syntactically, the two
    12301230         types of message differ only in the start-line, which is either a Request-Line (for requests) or a Status-Line (for responses),
    1231          and in the algorithm for determining the length of the message-body (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>). In theory, a client could receive requests and a server could receive responses, distinguishing them by their different
     1231         and in the algorithm for determining the length of the message body (<a href="#message.body" title="Message Body">Section&nbsp;3.3</a>). In theory, a client could receive requests and a server could receive responses, distinguishing them by their different
    12321232         start-line formats, but in practice servers are implemented to only expect a request (a response is interpreted as an unknown
    12331233         or invalid request method) and clients are implemented to only expect a response.
     
    14631463         status code (<a href="#status.code" title="Status Code">Section&nbsp;3.1.2.1</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g.,
    14641464         Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET.
    1465          All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message-body, although the body <em class="bcp14">MAY</em> be of zero length.
     1465         All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length.
    14661466      </p>
    14671467      <div id="rfc.iref.t.4"></div>
    14681468      <div id="rfc.iref.h.6"></div>
    14691469      <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;<a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h3>
    1470       <p id="rfc.section.3.3.1.p.1">When one or more transfer encodings are applied to a payload body in order to form the message-body, a Transfer-Encoding header
     1470      <p id="rfc.section.3.3.1.p.1">When one or more transfer encodings are applied to a payload body in order to form the message body, a Transfer-Encoding header
    14711471         field <em class="bcp14">MUST</em> be sent in the message and <em class="bcp14">MUST</em> contain the list of corresponding transfer-coding names in the same order that they were applied. Transfer encodings are defined
    14721472         in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5</a>.
     
    14791479      </p>
    14801480      <p id="rfc.section.3.3.1.p.4">The "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1</a>) <em class="bcp14">MUST</em> be implemented by all HTTP/1.1 recipients because it plays a crucial role in delimiting messages when the payload body size
    1481          is not known in advance. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message body and <em class="bcp14">MUST NOT</em> be applied more than once in a message-body. If any transfer-coding is applied to a request payload body, the final transfer-coding
     1481         is not known in advance. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message body and <em class="bcp14">MUST NOT</em> be applied more than once in a message body. If any transfer-coding is applied to a request payload body, the final transfer-coding
    14821482         applied <em class="bcp14">MUST</em> be "chunked". If any transfer-coding is applied to a response payload body, then either the final transfer-coding applied <em class="bcp14">MUST</em> be "chunked" or the message <em class="bcp14">MUST</em> be terminated by closing the connection.
    14831483      </p>
    14841484      <p id="rfc.section.3.3.1.p.5">For example,</p>
    14851485      <div id="rfc.figure.u.35"></div><pre class="text">  Transfer-Encoding: chunked
    1486 </pre><p id="rfc.section.3.3.1.p.7">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>, before determining the message-body length.
     1486</pre><p id="rfc.section.3.3.1.p.7">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>, before determining the message body length.
    14871487      </p>
    14881488      <p id="rfc.section.3.3.1.p.8">Unlike Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
     
    14971497      <div id="rfc.iref.h.7"></div>
    14981498      <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;<a id="header.content-length" href="#header.content-length">Content-Length</a></h3>
    1499       <p id="rfc.section.3.3.2.p.1">The "Content-Length" header field indicates the size of the message-body, in decimal number of octets, for any message other
     1499      <p id="rfc.section.3.3.2.p.1">The "Content-Length" header field indicates the size of the message body, in decimal number of octets, for any message other
    15001500         than a response to a HEAD request or a response with a status code of 304. In the case of a response to a HEAD request, Content-Length
    15011501         indicates the size of the payload body (not including any potential transfer-coding) that would have been sent had the request
     
    15061506</pre><p id="rfc.section.3.3.2.p.3">An example is</p>
    15071507      <div id="rfc.figure.u.37"></div><pre class="text">  Content-Length: 3495
    1508 </pre><p id="rfc.section.3.3.2.p.5">Implementations <em class="bcp14">SHOULD</em> use this field to indicate the message-body length when no transfer-coding is being applied and the payload's body length
    1509          can be determined prior to being transferred. <a href="#message.body" title="Message Body">Section&nbsp;3.3</a> describes how recipients determine the length of a message-body.
     1508</pre><p id="rfc.section.3.3.2.p.5">Implementations <em class="bcp14">SHOULD</em> use this field to indicate the message body length when no transfer-coding is being applied and the payload's body length
     1509         can be determined prior to being transferred. <a href="#message.body" title="Message Body">Section&nbsp;3.3</a> describes how recipients determine the length of a message body.
    15101510      </p>
    15111511      <p id="rfc.section.3.3.2.p.6">Any Content-Length greater than or equal to zero is a valid value.</p>
     
    15161516         a list of identical decimal values (e.g., "Content-Length: 42, 42"), indicating that duplicate Content-Length header fields
    15171517         have been generated or combined by an upstream message processor, then the recipient <em class="bcp14">MUST</em> either reject the message as invalid or replace the duplicated field-values with a single valid Content-Length field containing
    1518          that decimal value prior to determining the message-body length.
     1518         that decimal value prior to determining the message body length.
    15191519      </p>
    15201520      <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;<a id="message.body.length" href="#message.body.length">Message Body Length</a></h3>
    1521       <p id="rfc.section.3.3.3.p.1">The length of a message-body is determined by one of the following (in order of precedence):</p>
     1521      <p id="rfc.section.3.3.3.p.1">The length of a message body is determined by one of the following (in order of precedence):</p>
    15221522      <p id="rfc.section.3.3.3.p.2"> </p>
    15231523      <ol>
    15241524         <li>
    15251525            <p>Any response to a HEAD request and any response with a status code of 100-199, 204, or 304 is always terminated by the first
    1526                empty line after the header fields, regardless of the header fields present in the message, and thus cannot contain a message-body.
     1526               empty line after the header fields, regardless of the header fields present in the message, and thus cannot contain a message
     1527               body.
    15271528            </p>
    15281529         </li>
    15291530         <li>
    1530             <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding
     1531            <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;5.1</a>) is the final encoding, the message body length is determined by reading and decoding the chunked data until the transfer-coding
    15311532               indicates the data is complete.
    15321533            </p>
    15331534            <p>If a Transfer-Encoding header field is present in a response and the "chunked" transfer-coding is not the final encoding,
    1534                the message-body length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header
    1535                field is present in a request and the "chunked" transfer-coding is not the final encoding, the message-body length cannot
     1535               the message body length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header
     1536               field is present in a request and the "chunked" transfer-coding is not the final encoding, the message body length cannot
    15361537               be determined reliably; the server <em class="bcp14">MUST</em> respond with the 400 (Bad Request) status code and then close the connection.
    15371538            </p>
    15381539            <p>If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the Transfer-Encoding
    15391540               overrides the Content-Length. Such a message might indicate an attempt to perform request or response smuggling (bypass of
    1540                security-related checks on message routing or content) and thus ought to be handled as an error. The provided Content-Length <em class="bcp14">MUST</em> be removed, prior to forwarding the message downstream, or replaced with the real message-body length after the transfer-coding
     1541               security-related checks on message routing or content) and thus ought to be handled as an error. The provided Content-Length <em class="bcp14">MUST</em> be removed, prior to forwarding the message downstream, or replaced with the real message body length after the transfer-coding
    15411542               is decoded.
    15421543            </p>
     
    15501551         </li>
    15511552         <li>
    1552             <p>If a valid Content-Length header field is present without Transfer-Encoding, its decimal value defines the message-body length
     1553            <p>If a valid Content-Length header field is present without Transfer-Encoding, its decimal value defines the message body length
    15531554               in octets. If the actual number of octets sent in the message is less than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> consider the message to be incomplete and treat the connection as no longer usable. If the actual number of octets sent in
    1554                the message is more than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> only process the message-body up to the field value's number of octets; the remainder of the message <em class="bcp14">MUST</em> either be discarded or treated as the next message in a pipeline. For the sake of robustness, a user-agent <em class="bcp14">MAY</em> attempt to detect and correct such an error in message framing if it is parsing the response to the last request on a connection
     1555               the message is more than the indicated Content-Length, the recipient <em class="bcp14">MUST</em> only process the message body up to the field value's number of octets; the remainder of the message <em class="bcp14">MUST</em> either be discarded or treated as the next message in a pipeline. For the sake of robustness, a user-agent <em class="bcp14">MAY</em> attempt to detect and correct such an error in message framing if it is parsing the response to the last request on a connection
    15551556               and the connection has been closed by the server.
    15561557            </p>
    15571558         </li>
    15581559         <li>
    1559             <p>If this is a request message and none of the above are true, then the message-body length is zero (no message-body is present).</p>
     1560            <p>If this is a request message and none of the above are true, then the message body length is zero (no message body is present).</p>
    15601561         </li>
    15611562         <li>
    1562             <p>Otherwise, this is a response message without a declared message-body length, so the message-body length is determined by
     1563            <p>Otherwise, this is a response message without a declared message body length, so the message body length is determined by
    15631564               the number of octets received prior to the server closing the connection.
    15641565            </p>
     
    15691570         with HTTP/1.0.
    15701571      </p>
    1571       <p id="rfc.section.3.3.3.p.4">A server <em class="bcp14">MAY</em> reject a request that contains a message-body but not a Content-Length by responding with 411 (Length Required).
    1572       </p>
    1573       <p id="rfc.section.3.3.3.p.5">Unless a transfer-coding other than "chunked" has been applied, a client that sends a request containing a message-body <em class="bcp14">SHOULD</em> use a valid Content-Length header field if the message-body length is known in advance, rather than the "chunked" encoding,
     1572      <p id="rfc.section.3.3.3.p.4">A server <em class="bcp14">MAY</em> reject a request that contains a message body but not a Content-Length by responding with 411 (Length Required).
     1573      </p>
     1574      <p id="rfc.section.3.3.3.p.5">Unless a transfer-coding other than "chunked" has been applied, a client that sends a request containing a message body <em class="bcp14">SHOULD</em> use a valid Content-Length header field if the message body length is known in advance, rather than the "chunked" encoding,
    15741575         since some existing services respond to "chunked" with a 411 (Length Required) status code even though they understand the
    15751576         chunked encoding. This is typically because such services are implemented via a gateway that requires a content-length in
    15761577         advance of being called and the server is unable or unwilling to buffer the entire request before processing.
    15771578      </p>
    1578       <p id="rfc.section.3.3.3.p.6">A client that sends a request containing a message-body <em class="bcp14">MUST</em> include a valid Content-Length header field if it does not know the server will handle HTTP/1.1 (or later) requests; such
     1579      <p id="rfc.section.3.3.3.p.6">A client that sends a request containing a message body <em class="bcp14">MUST</em> include a valid Content-Length header field if it does not know the server will handle HTTP/1.1 (or later) requests; such
    15791580         knowledge can be in the form of specific user configuration or by remembering the version of a prior received response.
    15801581      </p>
     
    15831584      </p>
    15841585      <p id="rfc.section.3.4.p.2">Response messages that are prematurely terminated, usually by closure of the connection prior to receiving the expected number
    1585          of octets or by failure to decode a transfer-encoded message-body, <em class="bcp14">MUST</em> be recorded as incomplete. A response that terminates in the middle of the header block (before the empty line is received)
     1586         of octets or by failure to decode a transfer-encoded message body, <em class="bcp14">MUST</em> be recorded as incomplete. A response that terminates in the middle of the header block (before the empty line is received)
    15861587         cannot be assumed to convey the full semantics of the response and <em class="bcp14">MUST</em> be treated as an error.
    15871588      </p>
    1588       <p id="rfc.section.3.4.p.3">A message-body that uses the chunked transfer encoding is incomplete if the zero-sized chunk that terminates the encoding
    1589          has not been received. A message that uses a valid Content-Length is incomplete if the size of the message-body received (in
     1589      <p id="rfc.section.3.4.p.3">A message body that uses the chunked transfer encoding is incomplete if the zero-sized chunk that terminates the encoding
     1590         has not been received. A message that uses a valid Content-Length is incomplete if the size of the message body received (in
    15901591         octets) is less than the value given by Content-Length. A response that has neither chunked transfer encoding nor Content-Length
    1591          is terminated by closure of the connection, and thus is considered complete regardless of the number of message-body octets
     1592         is terminated by closure of the connection, and thus is considered complete regardless of the number of message body octets
    15921593         received, provided that the header block was received intact.
    15931594      </p>
    1594       <p id="rfc.section.3.4.p.4">A user agent <em class="bcp14">MUST NOT</em> render an incomplete response message-body as if it were complete (i.e., some indication must be given to the user that an
     1595      <p id="rfc.section.3.4.p.4">A user agent <em class="bcp14">MUST NOT</em> render an incomplete response message body as if it were complete (i.e., some indication must be given to the user that an
    15951596         error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Response Cacheability">Section 2.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
    15961597      </p>
    1597       <p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> read the entire request message-body or close the connection after sending its response, since otherwise the remaining data
    1598          on a persistent connection would be misinterpreted as the next request. Likewise, a client <em class="bcp14">MUST</em> read the entire response message-body if it intends to reuse the same connection for a subsequent request. Pipelining multiple
     1598      <p id="rfc.section.3.4.p.5">A server <em class="bcp14">MUST</em> read the entire request message body or close the connection after sending its response, since otherwise the remaining data
     1599         on a persistent connection would be misinterpreted as the next request. Likewise, a client <em class="bcp14">MUST</em> read the entire response message body if it intends to reuse the same connection for a subsequent request. Pipelining multiple
    15991600         requests on a connection is described in <a href="#pipelining" title="Pipelining">Section&nbsp;6.1.2.2</a>.
    16001601      </p>
    16011602      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2>
    16021603      <p id="rfc.section.3.5.p.1">Older HTTP/1.0 client implementations might send an extra CRLF after a POST request as a lame workaround for some early server
    1603          applications that failed to read message-body content that was not terminated by a line-ending. An HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. If terminating the request message-body with a line-ending is desired, then
    1604          the client <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message-body length.
     1604         applications that failed to read message body content that was not terminated by a line-ending. An HTTP/1.1 client <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. If terminating the request message body with a line-ending is desired, then
     1605         the client <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message body length.
    16051606      </p>
    16061607      <p id="rfc.section.3.5.p.2">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore at least one empty line received where a Request-Line is expected. In other words, if the server is reading the protocol
     
    20762077         </p>
    20772078      </div>
    2078       <p id="rfc.section.6.1.3.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message-body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5</a>).
     2079      <p id="rfc.section.6.1.3.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5</a>).
    20792080      </p>
    20802081      <h3 id="rfc.section.6.1.4"><a href="#rfc.section.6.1.4">6.1.4</a>&nbsp;<a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
     
    21142115      </p>
    21152116      <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;<a id="persistent.monitor" href="#persistent.monitor">Monitoring Connections for Error Status Messages</a></h3>
    2116       <p id="rfc.section.6.2.2.p.1">An HTTP/1.1 (or later) client sending a message-body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error
     2117      <p id="rfc.section.6.2.2.p.1">An HTTP/1.1 (or later) client sending a message body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error
    21172118         status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;5</a>), a zero length chunk and empty trailer <em class="bcp14">MAY</em> be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header field, the client <em class="bcp14">MUST</em> close the connection.
    21182119      </p>
Note: See TracChangeset for help on using the changeset viewer.