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.

Location:
draft-ietf-httpbis/latest
Files:
10 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>

  • 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;

  • draft-ietf-httpbis/latest/p2-semantics.html

    r1539 r1544  
    460460  }
    461461  @bottom-center {
    462        content: "Expires August 22, 2012";
     462       content: "Expires August 23, 2012";
    463463  }
    464464  @bottom-right {
    … …  
    513513      <meta name="dct.creator" content="Reschke, J. F.">
    514514      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    515       <meta name="dct.issued" scheme="ISO8601" content="2012-02-19">
     515      <meta name="dct.issued" scheme="ISO8601" content="2012-02-20">
    516516      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    517517      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields.">
    … …  
    544544            </tr>
    545545            <tr>
    546                <td class="left">Expires: August 22, 2012</td>
     546               <td class="left">Expires: August 23, 2012</td>
    547547               <td class="right">HP</td>
    548548            </tr>
    … …  
    597597            <tr>
    598598               <td class="left"></td>
    599                <td class="right">February 19, 2012</td>
     599               <td class="right">February 20, 2012</td>
    600600            </tr>
    601601         </tbody>
    … …  
    627627         in progress”.
    628628      </p>
    629       <p>This Internet-Draft will expire on August 22, 2012.</p>
     629      <p>This Internet-Draft will expire on August 23, 2012.</p>
    630630      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    631631      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    947947         to a single application, so that this is clear.
    948948      </p>
    949       <p id="rfc.section.2.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message-body on either the request or the response message
     949      <p id="rfc.section.2.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message body on either the request or the response message
    950950         (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they
    951951         can specify that only zero-length bodies (as opposed to absent bodies) are allowed.
    … …  
    14381438         in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
    14391439      </p>
    1440       <p id="rfc.section.5.p.2">A representation body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied
     1440      <p id="rfc.section.5.p.2">A representation body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message body by decoding any Transfer-Encoding that might have been applied
    14411441         to ensure safe and proper transfer of the message.
    14421442      </p>
    … …  
    14981498      </p>
    14991499      <p id="rfc.section.6.2.p.2">Responses to the OPTIONS method are not cacheable.</p>
    1500       <p id="rfc.section.6.2.p.3">If the OPTIONS request includes a message-body (as indicated by the presence of Content-Length or Transfer-Encoding), then
     1500      <p id="rfc.section.6.2.p.3">If the OPTIONS request includes a message body (as indicated by the presence of Content-Length or Transfer-Encoding), then
    15011501         the media type <em class="bcp14">MUST</em> be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions
    15021502         to HTTP might use the OPTIONS body to make more detailed queries on the server.
    … …  
    15431543      <div id="rfc.iref.h.1"></div>
    15441544      <div id="rfc.iref.m.3"></div>
    1545       <p id="rfc.section.6.4.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message-body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the
     1545      <p id="rfc.section.6.4.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the
    15461546         representation implied by the request without transferring the representation body. This method is often used for testing
    15471547         hypertext links for validity, accessibility, and recent modification.
    … …  
    16631663      <div id="rfc.iref.t.1"></div>
    16641664      <div id="rfc.iref.m.7"></div>
    1665       <p id="rfc.section.6.8.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message-body of a 200 (OK) response. The final recipient is either
    1666          the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section&nbsp;10.6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message-body.
     1665      <p id="rfc.section.6.8.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a 200 (OK) response. The final recipient is either
     1666         the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section&nbsp;10.6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.
    16671667      </p>
    16681668      <p id="rfc.section.6.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
    … …  
    16711671         infinite loop.
    16721672      </p>
    1673       <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.
     1673      <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.
    16741674      </p>
    16751675      <div id="rfc.iref.c.1"></div>
    … …  
    17681768         <dd>a representation of the target resource is sent in the response;</dd>
    17691769         <dt>HEAD</dt>
    1770          <dd>the same representation as GET, except without the message-body;</dd>
     1770         <dd>the same representation as GET, except without the message body;</dd>
    17711771         <dt>POST</dt>
    17721772         <dd>a representation describing or containing the result of the action;</dd>
    … …  
    18301830         automated data transfers to be prevalent, such as within distributed version control systems.
    18311831      </p>
    1832       <p id="rfc.section.7.2.5.p.5">The 204 response <em class="bcp14">MUST NOT</em> include a message-body, and thus is always terminated by the first empty line after the header fields.
     1832      <p id="rfc.section.7.2.5.p.5">The 204 response <em class="bcp14">MUST NOT</em> include a message body, and thus is always terminated by the first empty line after the header fields.
    18331833      </p>
    18341834      <div id="rfc.iref.29"></div>
    … …  
    18391839         another input action.
    18401840      </p>
    1841       <p id="rfc.section.7.2.6.p.2">The message-body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     1841      <p id="rfc.section.7.2.6.p.2">The message body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    18421842      </p>
    18431843      <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a>&nbsp;<a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2>
    … …  
    20642064      <div id="rfc.iref.s.26"></div>
    20652065      <h3 id="rfc.section.7.4.10"><a href="#rfc.section.7.4.10">7.4.10</a>&nbsp;<a id="status.411" href="#status.411">411 Length Required</a></h3>
    2066       <p id="rfc.section.7.4.10.p.1">The server refuses to accept the request without a defined Content-Length. The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message-body in the request
     2066      <p id="rfc.section.7.4.10.p.1">The server refuses to accept the request without a defined Content-Length. The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request
    20672067         message.
    20682068      </p>
    … …  
    34513451         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/276">http://tools.ietf.org/wg/httpbis/trac/ticket/276</a>&gt;: "untangle ABNFs for header fields"
    34523452         </li>
    3453          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/251">http://tools.ietf.org/wg/httpbis/trac/ticket/251</a>&gt;: "message-body in CONNECT request"
     3453         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/251">http://tools.ietf.org/wg/httpbis/trac/ticket/251</a>&gt;: "message body in CONNECT request"
    34543454         </li>
    34553455      </ul>

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1539 r1544  
    482482<t>
    483483   Due to the parsing rules defined in &message-body;, definitions of HTTP
    484    methods cannot prohibit the presence of a message-body on either the request
     484   methods cannot prohibit the presence of a message body on either the request
    485485   or the response message (with responses to HEAD requests being the single
    486486   exception). Definitions of new methods cannot change this rule, but they can
    … …  
    813813</t>
    814814<t>
    815    A representation body is only present in a message when a message-body is
     815   A representation body is only present in a message when a message body is
    816816   present, as described in &message-body;. The representation body is obtained
    817    from the message-body by decoding any Transfer-Encoding that might
     817   from the message body by decoding any Transfer-Encoding that might
    818818   have been applied to ensure safe and proper transfer of the message.
    819819</t>
    … …  
    929929</t>
    930930<t>
    931    If the OPTIONS request includes a message-body (as indicated by the
     931   If the OPTIONS request includes a message body (as indicated by the
    932932   presence of Content-Length or Transfer-Encoding), then the media type
    933933   &MUST; be indicated by a Content-Type field. Although this
    … …  
    10261026<t>
    10271027   The HEAD method is identical to GET except that the server &MUST-NOT;
    1028    return a message-body in the response. The metadata contained
     1028   return a message body in the response. The metadata contained
    10291029   in the HTTP header fields in response to a HEAD request &SHOULD; be identical
    10301030   to the information sent in response to a GET request. This method can
    … …  
    12711271   of the request message. The final recipient of the request
    12721272   &SHOULD; reflect the message received back to the client as the
    1273    message-body of a 200 (OK) response. The final recipient is either the
     1273   message body of a 200 (OK) response. The final recipient is either the
    12741274   origin server or the first proxy to receive a Max-Forwards
    12751275   value of zero (0) in the request (see <xref target="header.max-forwards"/>).
    1276    A TRACE request &MUST-NOT; include a message-body.
     1276   A TRACE request &MUST-NOT; include a message body.
    12771277</t>
    12781278<t>
    … …  
    12871287<t>
    12881288   If the request is valid, the response &SHOULD; have a Content-Type of
    1289    "message/http" (see &media-type-message-http;) and contain a message-body
     1289   "message/http" (see &media-type-message-http;) and contain a message body
    12901290   that encloses a copy of the entire request message.
    12911291   Responses to the TRACE method are not cacheable.
    … …  
    14871487    </t>
    14881488    <t hangText="HEAD">
    1489       the same representation as GET, except without the message-body;
     1489      the same representation as GET, except without the message body;
    14901490    </t>
    14911491    <t hangText="POST">
    … …  
    16041604</t>
    16051605<t>
    1606    The 204 response &MUST-NOT; include a message-body, and thus is always
     1606   The 204 response &MUST-NOT; include a message body, and thus is always
    16071607   terminated by the first empty line after the header fields.
    16081608</t>
    … …  
    16201620</t>
    16211621<t>   
    1622    The message-body included with the response &MUST; be empty. Note that
     1622   The message body included with the response &MUST; be empty. Note that
    16231623   receivers still need to parse the response according to the algorithm defined
    16241624   in &message-body;.
    … …  
    20492049   The server refuses to accept the request without a defined Content-Length.
    20502050   The client &MAY; repeat the request if it adds a valid
    2051    Content-Length header field containing the length of the message-body
     2051   Content-Length header field containing the length of the message body
    20522052   in the request message.
    20532053</t>
    … …  
    45864586    <t>
    45874587      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/251"/>:
    4588       "message-body in CONNECT request"
     4588      "message body in CONNECT request"
    45894589    </t>
    45904590  </list>

  • draft-ietf-httpbis/latest/p3-payload.html

    r1528 r1544  
    460460  }
    461461  @bottom-center {
    462        content: "Expires August 10, 2012";
     462       content: "Expires August 23, 2012";
    463463  }
    464464  @bottom-right {
    … …  
    511511      <meta name="dct.creator" content="Reschke, J. F.">
    512512      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    513       <meta name="dct.issued" scheme="ISO8601" content="2012-02-07">
     513      <meta name="dct.issued" scheme="ISO8601" content="2012-02-20">
    514514      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    515515      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
    … …  
    537537            </tr>
    538538            <tr>
    539                <td class="left">Expires: August 10, 2012</td>
     539               <td class="left">Expires: August 23, 2012</td>
    540540               <td class="right">J. Mogul</td>
    541541            </tr>
    … …  
    594594            <tr>
    595595               <td class="left"></td>
    596                <td class="right">February 7, 2012</td>
     596               <td class="right">February 20, 2012</td>
    597597            </tr>
    598598         </tbody>
    … …  
    622622         in progress”.
    623623      </p>
    624       <p>This Internet-Draft will expire on August 10, 2012.</p>
     624      <p>This Internet-Draft will expire on August 23, 2012.</p>
    625625      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    626626      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    799799      <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">absolute-URI</a>   = &lt;absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    800800  <a href="#abnf.dependencies" class="smpl">partial-URI</a>    = &lt;partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    801   <a href="#abnf.dependencies" class="smpl">qvalue</a>         = &lt;qvalue, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a>&gt;
     801  <a href="#abnf.dependencies" class="smpl">qvalue</a>         = &lt;qvalue, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.4.1</a>&gt;
    802802</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1>
    803803      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="character.sets" href="#character.sets">Character Encodings (charset)</a></h2>
    … …  
    831831      </p>
    832832      <ul class="empty">
    833          <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     833         <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    834834         </li>
    835835      </ul>
    … …  
    837837      </p>
    838838      <ul class="empty">
    839          <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.1.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     839         <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    840840         </li>
    841841      </ul>
    … …  
    843843      </p>
    844844      <ul class="empty">
    845          <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.1.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
     845         <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
    846846         </li>
    847847      </ul>
    … …  
    855855         <li>Pointer to specification text</li>
    856856      </ul>
    857       <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5.1</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 5.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     857      <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 5.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    858858      </p>
    859859      <p id="rfc.section.2.2.1.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of content coding defined in this section.
    … …  
    900900      </p>
    901901      <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="multipart.types" href="#multipart.types">Multipart Types</a></h3>
    902       <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types — encapsulations of one or more representations within a single message-body.
     902      <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types — encapsulations of one or more representations within a single message body.
    903903         All multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts.
    904904      </p>
    905       <p id="rfc.section.2.3.2.p.2">In general, HTTP treats a multipart message-body no differently than any other media type: strictly as payload. HTTP does
    906          not use the multipart boundary as an indicator of message-body length.  In all other respects, an HTTP user agent <em class="bcp14">SHOULD</em> follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. The MIME header fields within
    907          each body-part of a multipart message-body do not have any significance to HTTP beyond that defined by their MIME semantics.
     905      <p id="rfc.section.2.3.2.p.2">In general, HTTP treats a multipart message body no differently than any other media type: strictly as payload. HTTP does
     906         not use the multipart boundary as an indicator of message body length.  In all other respects, an HTTP user agent <em class="bcp14">SHOULD</em> follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. The MIME header fields within
     907         each body-part of a multipart message body do not have any significance to HTTP beyond that defined by their MIME semantics.
    908908      </p>
    909909      <p id="rfc.section.2.3.2.p.3">If an application receives an unrecognized multipart subtype, the application <em class="bcp14">MUST</em> treat it as being equivalent to "multipart/mixed".
    … …  
    932932      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="payload" href="#payload">Payload</a></h1>
    933933      <p id="rfc.section.3.p.1">HTTP messages <em class="bcp14">MAY</em> transfer a payload if not otherwise restricted by the request method or response status code. The payload consists of metadata,
    934          in the form of header fields, and data, in the form of the sequence of octets in the message-body after any transfer-coding
     934         in the form of header fields, and data, in the form of the sequence of octets in the message body after any transfer-coding
    935935         has been decoded.
    936936      </p>
    … …  
    955955               <tr>
    956956                  <td class="left">Content-Length</td>
    957                   <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 8.2</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
     957                  <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
    958958               </tr>
    959959               <tr>
    … …  
    965965      </div>
    966966      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="payload.body" href="#payload.body">Payload Body</a></h2>
    967       <p id="rfc.section.3.2.p.1">A payload body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure
     967      <p id="rfc.section.3.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any Transfer-Encoding that might have been applied to ensure
    968968         safe and proper transfer of the message.
    969969      </p>
    … …  
    984984      </p>
    985985      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h2>
    986       <p id="rfc.section.4.1.p.1">Representation header fields define metadata about the representation data enclosed in the message-body or, if no message-body
    987          is present, about the representation that would have been transferred in a 200 response to a simultaneous GET request with
    988          the same effective request URI.
     986      <p id="rfc.section.4.1.p.1">Representation header fields define metadata about the representation data enclosed in the message body or, if no message
     987         body is present, about the representation that would have been transferred in a 200 response to a simultaneous GET request
     988         with the same effective request URI.
    989989      </p>
    990990      <p id="rfc.section.4.1.p.2">The following header fields are defined as representation metadata:</p>
    … …  
    11011101         that doesn't conform to them is better than sending a 406 (Not Acceptable) response.
    11021102      </p>
    1103       <p id="rfc.section.5.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information.
     1103      <p id="rfc.section.5.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.4.1</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information.
    11041104      </p>
    11051105      <p id="rfc.section.5.1.p.6">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities
    1106          and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;6.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information
     1106         and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;6.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 10.10</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information
    11071107         within extension header fields not defined by this specification.
    11081108      </p>
    … …  
    11541154      <p id="rfc.section.6.1.p.4">Each media-range <em class="bcp14">MAY</em> be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first
    11551155         "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user
    1156          agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1.
     1156         agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.4.1</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1.
    11571157      </p>
    11581158      <div class="note" id="rfc.section.6.1.p.5">
    … …  
    12841284         </li>
    12851285         <li>If the representation's content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable
    1286             unless it is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".)
     1286            unless it is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.4.1</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".)
    12871287         </li>
    12881288         <li>If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.</li>
    … …  
    15461546                  <td class="left">compress</td>
    15471547                  <td class="left">UNIX "compress" program method</td>
    1548                   <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
     1548                  <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
    15491549                  </td>
    15501550               </tr>
    … …  
    15531553                  <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>)
    15541554                  </td>
    1555                   <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.1.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
     1555                  <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
    15561556                  </td>
    15571557               </tr>
    … …  
    15591559                  <td class="left">gzip</td>
    15601560                  <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td>
    1561                   <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.1.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
     1561                  <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
    15621562                  </td>
    15631563               </tr>
    … …  
    17771777      </div>
    17781778      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a id="differences.between.http.and.mime" href="#differences.between.http.and.mime">Differences between HTTP and MIME</a></h1>
    1779       <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow a message-body to be transmitted in an open variety of representations and with extensible mechanisms. However,
     1779      <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow a message body to be transmitted in an open variety of representations and with extensible mechanisms. However,
    17801780         RFC 2045 discusses mail, and HTTP has a few features that are different from those described in MIME. These differences were
    17811781         carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types,
    … …  
    18291829      </p>
    18301830      <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a>&nbsp;<a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h2>
    1831       <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 8.6</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.
     1831      <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.
    18321832      </p>
    18331833      <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a>&nbsp;<a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2>
    … …  
    22472247                        <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a></li>
    22482248                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">3.2</a></li>
     2249                        <li><em>Section 3.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.25">A.6</a></li>
     2250                        <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">3.1</a></li>
    22492251                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.20">6.7</a></li>
    2250                         <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">2.2.1</a></li>
    2251                         <li><em>Section 5.1.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.21">7.2</a></li>
    2252                         <li><em>Section 5.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">2.2.1</a></li>
    2253                         <li><em>Section 5.1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.22">7.2</a></li>
    2254                         <li><em>Section 5.1.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.23">7.2</a></li>
    2255                         <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">1.3.2</a>, <a href="#rfc.xref.Part1.17">5.1</a>, <a href="#rfc.xref.Part1.18">6.1</a>, <a href="#rfc.xref.Part1.19">6.3</a></li>
    2256                         <li><em>Section 8.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">3.1</a></li>
    2257                         <li><em>Section 8.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.25">A.6</a></li>
     2252                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">2.2.1</a></li>
     2253                        <li><em>Section 5.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.21">7.2</a></li>
     2254                        <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">2.2.1</a></li>
     2255                        <li><em>Section 5.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.22">7.2</a></li>
     2256                        <li><em>Section 5.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.23">7.2</a></li>
     2257                        <li><em>Section 5.4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">1.3.2</a>, <a href="#rfc.xref.Part1.17">5.1</a>, <a href="#rfc.xref.Part1.18">6.1</a>, <a href="#rfc.xref.Part1.19">6.3</a></li>
    22582258                        <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">9</a></li>
    22592259                     </ul>
    … …  
    22612261                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">5.1</a>, <a href="#Part2"><b>10.1</b></a>, <a href="#rfc.xref.Part2.2">A.3</a><ul>
    22622262                        <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">A.3</a></li>
    2263                         <li><em>Section 9.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">5.1</a></li>
     2263                        <li><em>Section 10.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">5.1</a></li>
    22642264                     </ul>
    22652265                  </li>

  • draft-ietf-httpbis/latest/p3-payload.xml

    r1523 r1544  
    558558<t>
    559559   MIME provides for a number of "multipart" types &mdash; encapsulations of
    560    one or more representations within a single message-body. All multipart
     560   one or more representations within a single message body. All multipart
    561561   types share a common syntax, as defined in <xref target="RFC2046" x:sec="5.1.1" x:fmt="of"/>,
    562562   and &MUST; include a boundary parameter as part of the media type
    … …  
    565565</t>
    566566<t>
    567    In general, HTTP treats a multipart message-body no differently than
     567   In general, HTTP treats a multipart message body no differently than
    568568   any other media type: strictly as payload.  HTTP does not use the
    569    multipart boundary as an indicator of message-body length.
     569   multipart boundary as an indicator of message body length.
    570570   <!-- jre: re-insert removed text pointing to caching? -->
    571571   In all other respects, an HTTP user agent &SHOULD; follow the same or similar
    572572   behavior as a MIME user agent would upon receipt of a multipart type.
    573    The MIME header fields within each body-part of a multipart message-body
     573   The MIME header fields within each body-part of a multipart message body
    574574   do not have any significance to HTTP beyond that defined by
    575575   their MIME semantics.
    … …  
    627627   the request method or response status code.  The payload consists of
    628628   metadata, in the form of header fields, and data, in the form of the
    629    sequence of octets in the message-body after any transfer-coding has
     629   sequence of octets in the message body after any transfer-coding has
    630630   been decoded.
    631631</t>
    … …  
    657657  <x:anchor-alias value="payload-body"/>
    658658<t>
    659    A payload body is only present in a message when a message-body is
     659   A payload body is only present in a message when a message body is
    660660   present, as described in &message-body;. The payload body is obtained
    661    from the message-body by decoding any Transfer-Encoding that might
     661   from the message body by decoding any Transfer-Encoding that might
    662662   have been applied to ensure safe and proper transfer of the message.
    663663</t>
    … …  
    694694<t>
    695695   Representation header fields define metadata about the representation data
    696    enclosed in the message-body or, if no message-body is present, about
     696   enclosed in the message body or, if no message body is present, about
    697697   the representation that would have been transferred in a 200 response
    698698   to a simultaneous GET request with the same effective request URI.
    … …  
    23632363<t>
    23642364   HTTP/1.1 uses many of the constructs defined for Internet Mail (<xref target="RFC5322"/>) and the Multipurpose Internet Mail Extensions (MIME <xref target="RFC2045"/>) to
    2365    allow a message-body to be transmitted in an open variety of
     2365   allow a message body to be transmitted in an open variety of
    23662366   representations and with extensible mechanisms. However, RFC 2045
    23672367   discusses mail, and HTTP has a few features that are different from

  • draft-ietf-httpbis/latest/p5-range.html

    r1543 r1544  
    806806      <ul>
    807807         <li>Either a Content-Range header field (<a href="#header.content-range" id="rfc.xref.header.content-range.2" title="Content-Range">Section&nbsp;5.2</a>) indicating the range included with this response, or a multipart/byteranges Content-Type including Content-Range fields
    808             for each part. If a Content-Length header field is present in the response, its value <em class="bcp14">MUST</em> match the actual number of octets transmitted in the message-body.
     808            for each part. If a Content-Length header field is present in the response, its value <em class="bcp14">MUST</em> match the actual number of octets transmitted in the message body.
    809809         </li>
    810810         <li>Date</li>
    … …  
    878878         header fields in the stored response.
    879879      </p>
    880       <p id="rfc.section.4.2.p.5">The combined response message-body consists of the union of partial content ranges in the new response and each of the selected
     880      <p id="rfc.section.4.2.p.5">The combined response message body consists of the union of partial content ranges in the new response and each of the selected
    881881         responses. If the union consists of the entire range of the representation, then the combined response <em class="bcp14">MUST</em> be recorded as a complete 200 (OK) response with a Content-Length header field that reflects the complete length. Otherwise,
    882882         the combined response(s) <em class="bcp14">MUST</em> include a Content-Range header field describing the included range(s) and be recorded as incomplete. If the union consists
    … …  
    988988      </p>
    989989      <p id="rfc.section.5.4.1.p.2">Byte range specifications in HTTP apply to the sequence of bytes in the representation body (not necessarily the same as the
    990          message-body).
     990         message body).
    991991      </p>
    992992      <div id="rule.ranges-specifier">
    … …  
    12671267      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a id="internet.media.type.multipart.byteranges" href="#internet.media.type.multipart.byteranges">Internet Media Type multipart/byteranges</a></h1>
    12681268      <p id="rfc.section.A.p.1">When an HTTP 206 (Partial Content) response message includes the content of multiple ranges (a response to a request for multiple
    1269          non-overlapping ranges), these are transmitted as a multipart message-body (<a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-5.1">Section 5.1</a>). The media type for this purpose is called "multipart/byteranges". The following is to be registered with IANA <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>.
     1269         non-overlapping ranges), these are transmitted as a multipart message body (<a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-5.1">Section 5.1</a>). The media type for this purpose is called "multipart/byteranges". The following is to be registered with IANA <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>.
    12701270      </p>
    12711271      <div class="note" id="rfc.section.A.p.2">

  • draft-ietf-httpbis/latest/p5-range.xml

    r1543 r1544  
    416416        Content-Length header field is present in the response, its
    417417        value &MUST; match the actual number of octets transmitted in the
    418         message-body.
     418        message body.
    419419    </t>
    420420    <t>
    … …  
    556556</t>
    557557<t>
    558    The combined response message-body consists of the union of partial
     558   The combined response message body consists of the union of partial
    559559   content ranges in the new response and each of the selected responses.
    560560   If the union consists of the entire range of the representation, then the
    … …  
    786786<t>
    787787   Byte range specifications in HTTP apply to the sequence of bytes in
    788    the representation body (not necessarily the same as the message-body).
     788   the representation body (not necessarily the same as the message body).
    789789</t>
    790790<t anchor="rule.ranges-specifier">
    … …  
    14091409   content of multiple ranges (a response to a request for multiple
    14101410   non-overlapping ranges), these are transmitted as a multipart
    1411    message-body (<xref target="RFC2046" x:fmt="," x:sec="5.1"/>). The media type for this purpose is called
     1411   message body (<xref target="RFC2046" x:fmt="," x:sec="5.1"/>). The media type for this purpose is called
    14121412   "multipart/byteranges".  The following is to be registered with IANA <xref target="RFC4288"/>.
    14131413</t>

  • draft-ietf-httpbis/latest/p6-cache.html

    r1531 r1544  
    463463  }
    464464  @bottom-center {
    465        content: "Expires August 10, 2012";
     465       content: "Expires August 23, 2012";
    466466  }
    467467  @bottom-right {
    … …  
    511511      <meta name="dct.creator" content="Reschke, J. F.">
    512512      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    513       <meta name="dct.issued" scheme="ISO8601" content="2012-02-07">
     513      <meta name="dct.issued" scheme="ISO8601" content="2012-02-20">
    514514      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    515515      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
    … …  
    537537            </tr>
    538538            <tr>
    539                <td class="left">Expires: August 10, 2012</td>
     539               <td class="left">Expires: August 23, 2012</td>
    540540               <td class="right">J. Mogul</td>
    541541            </tr>
    … …  
    602602            <tr>
    603603               <td class="left"></td>
    604                <td class="right">February 7, 2012</td>
     604               <td class="right">February 20, 2012</td>
    605605            </tr>
    606606         </tbody>
    … …  
    632632         in progress”.
    633633      </p>
    634       <p>This Internet-Draft will expire on August 10, 2012.</p>
     634      <p>This Internet-Draft will expire on August 23, 2012.</p>
    635635      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    636636      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    879879  <a href="#abnf.dependencies" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 8</a>&gt;
    880880  <a href="#abnf.dependencies" class="smpl">port</a>          = &lt;port, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    881   <a href="#abnf.dependencies" class="smpl">pseudonym</a>     = &lt;pseudonym, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a>&gt;
     881  <a href="#abnf.dependencies" class="smpl">pseudonym</a>     = &lt;pseudonym, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.via" title="Via">Section 8.4</a>&gt;
    882882  <a href="#abnf.dependencies" class="smpl">uri-host</a>      = &lt;uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    883883</pre><h2 id="rfc.section.1.5"><a href="#rfc.section.1.5">1.5</a>&nbsp;<a id="delta-seconds" href="#delta-seconds">Delta Seconds</a></h2>
    … …  
    941941      </p>
    942942      <p id="rfc.section.2.1.p.5">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is 200 (OK), and the entire
    943          response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message-body if the cache entry is recorded as incomplete. Likewise, a 206 (Partial Content)
     943         response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a 206 (Partial Content)
    944944         response <em class="bcp14">MAY</em> be stored as if it were an incomplete 200 (OK) cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the Range and Content-Range header fields or if it does
    945945         not understand the range units used in those fields.
    … …  
    10591059         <li>HTTP/1.1 requires origin servers to send a Date header field, if possible, with every response, giving the time at which the
    10601060            response was generated. The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic
    1061             operations. See <a href="p2-semantics.html#header.date" title="Date">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
     1061            operations. See <a href="p2-semantics.html#header.date" title="Date">Section 10.2</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
    10621062         </li>
    10631063      </ul>
    … …  
    12451245      <p id="rfc.section.2.8.p.1">A response might transfer only a partial representation if the connection closed prematurely or if the request used one or
    12461246         more Range specifiers (<a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>). After several such transfers, a cache might have received several ranges of the same representation. A cache <em class="bcp14">MAY</em> combine these ranges into a single stored response, and reuse that response to satisfy later requests, if they all share the
    1247          same strong validator and the cache complies with the client requirements in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>.
     1247         same strong validator and the cache complies with the client requirements in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4.2</a> of <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>.
    12481248      </p>
    12491249      <p id="rfc.section.2.8.p.2">When combining the new response with one or more stored responses, a cache <em class="bcp14">MUST</em>:
    … …  
    24512451                        <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">1.4.1</a>, <a href="#rfc.xref.Part1.6">1.4.1</a></li>
    24522452                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.13">2.5</a>, <a href="#rfc.xref.Part1.14">2.5</a>, <a href="#rfc.xref.Part1.15">2.5</a></li>
    2453                         <li><em>Section 8.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">1.4.2</a></li>
     2453                        <li><em>Section 8.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">1.4.2</a></li>
    24542454                        <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.17">7</a></li>
    24552455                     </ul>
    … …  
    24592459                        <li><em>Section 7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.3.1.1</a></li>
    24602460                        <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1.4.2</a>, <a href="#rfc.xref.Part2.7">3.3</a></li>
    2461                         <li><em>Section 9.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">2.3.2</a></li>
     2461                        <li><em>Section 10.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">2.3.2</a></li>
    24622462                     </ul>
    24632463                  </li>
    … …  
    24702470                  </li>
    24712471                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">2.1</a>, <a href="#rfc.xref.Part5.2">2.8</a>, <a href="#rfc.xref.Part5.3">2.8</a>, <a href="#Part5"><b>8.1</b></a><ul>
    2472                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.3">2.8</a></li>
     2472                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.3">2.8</a></li>
    24732473                     </ul>
    24742474                  </li>

  • draft-ietf-httpbis/latest/p6-cache.xml

    r1530 r1544  
    595595   If the request is GET, the response status is 200 (OK), and the entire
    596596   response header block has been received, a cache &MAY; store an incomplete
    597    response message-body if the cache entry is recorded as incomplete.
     597   response message body if the cache entry is recorded as incomplete.
    598598   Likewise, a 206 (Partial Content) response &MAY; be stored as if it were
    599599   an incomplete 200 (OK) cache entry.  However, a cache &MUST-NOT; store
Note: See TracChangeset for help on using the changeset viewer.