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.xml

    r1540 r1544  
    10421042   <xref target="RFC5322"/>: zero or more header fields (collectively
    10431043   referred to as the "headers" or the "header section"), an empty line
    1044    indicating the end of the header section, and an optional message-body.
     1044   indicating the end of the header section, and an optional message body.
    10451045</t>
    10461046<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-message"/>
     
    10541054   start-line into a structure, read each header field into a hash
    10551055   table by field name until the empty line, and then use the parsed
    1056    data to determine if a message-body is expected.  If a message-body
     1056   data to determine if a message body is expected.  If a message body
    10571057   has been indicated, then it is read as a stream until an amount
    1058    of octets equal to the message-body length is read or the connection
     1058   of octets equal to the message body length is read or the connection
    10591059   is closed.
    10601060</t>
     
    10851085   differ only in the start-line, which is either a Request-Line (for requests)
    10861086   or a Status-Line (for responses), and in the algorithm for determining
    1087    the length of the message-body (<xref target="message.body"/>).
     1087   the length of the message body (<xref target="message.body"/>).
    10881088   In theory, a client could receive requests and a server could receive
    10891089   responses, distinguishing them by their different start-line formats,
     
    15781578   All 1xx (Informational), 204 (No Content), and 304 (Not Modified)
    15791579   responses &MUST-NOT; include a message body.
    1580    All other responses do include a message-body, although the body
     1580   All other responses do include a message body, although the body
    15811581   &MAY; be of zero length.
    15821582</t>
     
    15881588<t>
    15891589   When one or more transfer encodings are applied to a payload body in order
    1590    to form the message-body, a Transfer-Encoding header field &MUST; be sent
     1590   to form the message body, a Transfer-Encoding header field &MUST; be sent
    15911591   in the message and &MUST; contain the list of corresponding
    15921592   transfer-coding names in the same order that they were applied.
     
    16131613   When the "chunked" transfer-coding is used, it &MUST; be the last
    16141614   transfer-coding applied to form the message body and &MUST-NOT;
    1615    be applied more than once in a message-body.
     1615   be applied more than once in a message body.
    16161616   If any transfer-coding is applied to a request payload body,
    16171617   the final transfer-coding applied &MUST; be "chunked".
     
    16301630   the multiple field-values &MUST; be combined into one field-value,
    16311631   according to the algorithm defined in <xref target="header.fields"/>,
    1632    before determining the message-body length.
     1632   before determining the message body length.
    16331633</t>
    16341634<t>
     
    16631663<t>
    16641664   The "Content-Length" header field indicates the size of the
    1665    message-body, in decimal number of octets, for any message other than
     1665   message body, in decimal number of octets, for any message other than
    16661666   a response to a HEAD request or a response with a status code of 304.
    16671667   In the case of a response to a HEAD request, Content-Length indicates
     
    16831683</artwork></figure>
    16841684<t>
    1685    Implementations &SHOULD; use this field to indicate the message-body
     1685   Implementations &SHOULD; use this field to indicate the message body
    16861686   length when no transfer-coding is being applied and the
    16871687   payload's body length can be determined prior to being transferred.
    16881688   <xref target="message.body"/> describes how recipients determine the length
    1689    of a message-body.
     1689   of a message body.
    16901690</t>
    16911691<t>
     
    17061706   processor, then the recipient &MUST; either reject the message as invalid
    17071707   or replace the duplicated field-values with a single valid Content-Length
    1708    field containing that decimal value prior to determining the message-body
     1708   field containing that decimal value prior to determining the message body
    17091709   length.
    17101710</t>
     
    17131713<section title="Message Body Length" anchor="message.body.length">
    17141714<t>
    1715    The length of a message-body is determined by one of the following
     1715   The length of a message body is determined by one of the following
    17161716   (in order of precedence):
    17171717</t>
     
    17221722     code of 100-199, 204, or 304 is always terminated by the first
    17231723     empty line after the header fields, regardless of the header
    1724      fields present in the message, and thus cannot contain a message-body.
     1724     fields present in the message, and thus cannot contain a message body.
    17251725    </t></x:lt>
    17261726    <x:lt><t>
    17271727     If a Transfer-Encoding header field is present
    17281728     and the "chunked" transfer-coding (<xref target="chunked.encoding"/>)
    1729      is the final encoding, the message-body length is determined by reading
     1729     is the final encoding, the message body length is determined by reading
    17301730     and decoding the chunked data until the transfer-coding indicates the
    17311731     data is complete.
     
    17331733    <t>
    17341734     If a Transfer-Encoding header field is present in a response and the
    1735      "chunked" transfer-coding is not the final encoding, the message-body
     1735     "chunked" transfer-coding is not the final encoding, the message body
    17361736     length is determined by reading the connection until it is closed by
    17371737     the server.
    17381738     If a Transfer-Encoding header field is present in a request and the
    1739      "chunked" transfer-coding is not the final encoding, the message-body
     1739     "chunked" transfer-coding is not the final encoding, the message body
    17401740     length cannot be determined reliably; the server &MUST; respond with
    17411741     the 400 (Bad Request) status code and then close the connection.
     
    17491749     and thus ought to be handled as an error.  The provided Content-Length &MUST;
    17501750     be removed, prior to forwarding the message downstream, or replaced with
    1751      the real message-body length after the transfer-coding is decoded.
     1751     the real message body length after the transfer-coding is decoded.
    17521752    </t></x:lt>
    17531753    <x:lt><t>
     
    17681768     If a valid Content-Length header field
    17691769     is present without Transfer-Encoding, its decimal value defines the
    1770      message-body length in octets.  If the actual number of octets sent in
     1770     message body length in octets.  If the actual number of octets sent in
    17711771     the message is less than the indicated Content-Length, the recipient
    17721772     &MUST; consider the message to be incomplete and treat the connection
    17731773     as no longer usable.
    17741774     If the actual number of octets sent in the message is more than the indicated
    1775      Content-Length, the recipient &MUST; only process the message-body up to the
     1775     Content-Length, the recipient &MUST; only process the message body up to the
    17761776     field value's number of octets; the remainder of the message &MUST; either
    17771777     be discarded or treated as the next message in a pipeline.  For the sake of
     
    17821782    <x:lt><t>
    17831783     If this is a request message and none of the above are true, then the
    1784      message-body length is zero (no message-body is present).
     1784     message body length is zero (no message body is present).
    17851785    </t></x:lt>
    17861786    <x:lt><t>
    1787      Otherwise, this is a response message without a declared message-body
    1788      length, so the message-body length is determined by the number of octets
     1787     Otherwise, this is a response message without a declared message body
     1788     length, so the message body length is determined by the number of octets
    17891789     received prior to the server closing the connection.
    17901790    </t></x:lt>
     
    17991799</t>
    18001800<t>
    1801    A server &MAY; reject a request that contains a message-body but
     1801   A server &MAY; reject a request that contains a message body but
    18021802   not a Content-Length by responding with 411 (Length Required).
    18031803</t>
    18041804<t>
    18051805   Unless a transfer-coding other than "chunked" has been applied,
    1806    a client that sends a request containing a message-body &SHOULD;
    1807    use a valid Content-Length header field if the message-body length
     1806   a client that sends a request containing a message body &SHOULD;
     1807   use a valid Content-Length header field if the message body length
    18081808   is known in advance, rather than the "chunked" encoding, since some
    18091809   existing services respond to "chunked" with a 411 (Length Required)
     
    18141814</t>
    18151815<t>
    1816    A client that sends a request containing a message-body &MUST; include a
     1816   A client that sends a request containing a message body &MUST; include a
    18171817   valid Content-Length header field if it does not know the server will
    18181818   handle HTTP/1.1 (or later) requests; such knowledge can be in the form
     
    18331833   Response messages that are prematurely terminated, usually by closure
    18341834   of the connection prior to receiving the expected number of octets or by
    1835    failure to decode a transfer-encoded message-body, &MUST; be recorded
     1835   failure to decode a transfer-encoded message body, &MUST; be recorded
    18361836   as incomplete.  A response that terminates in the middle of the header
    18371837   block (before the empty line is received) cannot be assumed to convey the
     
    18391839</t>
    18401840<t>
    1841    A message-body that uses the chunked transfer encoding is
     1841   A message body that uses the chunked transfer encoding is
    18421842   incomplete if the zero-sized chunk that terminates the encoding has not
    18431843   been received.  A message that uses a valid Content-Length is incomplete
    1844    if the size of the message-body received (in octets) is less than the
     1844   if the size of the message body received (in octets) is less than the
    18451845   value given by Content-Length.  A response that has neither chunked
    18461846   transfer encoding nor Content-Length is terminated by closure of the
    18471847   connection, and thus is considered complete regardless of the number of
    1848    message-body octets received, provided that the header block was received
     1848   message body octets received, provided that the header block was received
    18491849   intact.
    18501850</t>
    18511851<t>
    1852    A user agent &MUST-NOT; render an incomplete response message-body as if
     1852   A user agent &MUST-NOT; render an incomplete response message body as if
    18531853   it were complete (i.e., some indication must be given to the user that an
    18541854   error occurred).  Cache requirements for incomplete responses are defined
     
    18561856</t>
    18571857<t>
    1858    A server &MUST; read the entire request message-body or close
     1858   A server &MUST; read the entire request message body or close
    18591859   the connection after sending its response, since otherwise the
    18601860   remaining data on a persistent connection would be misinterpreted
    18611861   as the next request.  Likewise,
    1862    a client &MUST; read the entire response message-body if it intends
     1862   a client &MUST; read the entire response message body if it intends
    18631863   to reuse the same connection for a subsequent request.  Pipelining
    18641864   multiple requests on a connection is described in <xref target="pipelining"/>.
     
    18701870   Older HTTP/1.0 client implementations might send an extra CRLF
    18711871   after a POST request as a lame workaround for some early server
    1872    applications that failed to read message-body content that was
     1872   applications that failed to read message body content that was
    18731873   not terminated by a line-ending. An HTTP/1.1 client &MUST-NOT;
    18741874   preface or follow a request with an extra CRLF.  If terminating
    1875    the request message-body with a line-ending is desired, then the
     1875   the request message body with a line-ending is desired, then the
    18761876   client &MUST; include the terminating CRLF octets as part of the
    1877    message-body length.
     1877   message body length.
    18781878</t>
    18791879<t>
     
    27902790<t>
    27912791   A non-transforming proxy &MUST; preserve the message payload (&payload;),
    2792    though it &MAY; change the message-body through application or removal
     2792   though it &MAY; change the message body through application or removal
    27932793   of a transfer-coding (<xref target="transfer.codings"/>).
    27942794</t>
     
    28782878<section title="Monitoring Connections for Error Status Messages" anchor="persistent.monitor">
    28792879<t>
    2880    An HTTP/1.1 (or later) client sending a message-body &SHOULD; monitor
     2880   An HTTP/1.1 (or later) client sending a message body &SHOULD; monitor
    28812881   the network connection for an error status code while it is transmitting
    28822882   the request. If the client sees an error status code, it &SHOULD;
Note: See TracChangeset for help on using the changeset viewer.