Ignore:
Timestamp:
Jul 27, 2010, 8:04:03 PM (9 years ago)
Author:
fielding@…
Message:

Further clarify the message body length calculation
so that transfer-encoding always overrides content-length.
Related to changeset [852]

File:
1 edited

Legend:

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

    r953 r957  
    12191219      <p id="rfc.section.3.3.p.5">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field
    12201220         in the request's header fields, even if the request method does not define any use for a message-body. This allows the request
    1221          message framing algorithm to be independent of method semantics. A server <em class="bcp14">MUST</em> read the entire request message-body or close the connection after sending its response.
     1221         message framing algorithm to be independent of method semantics.
    12221222      </p>
    12231223      <p id="rfc.section.3.3.p.6">For response messages, whether or not a message-body is included with a message is dependent on both the request method and
     
    12351235         </li>
    12361236         <li>
    1237             <p>If a Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;9.7</a>) is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>) is used, the message-body length is determined by reading and decoding the chunked data until the transfer-coding indicates
    1238                the data is complete.
     1237            <p>If a Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;9.7</a>) is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding
     1238               indicates the data is complete.
     1239            </p>
     1240            <p>If a Transfer-Encoding header field is present in a response and the "chunked" transfer-coding is not the final encoding,
     1241               the message-body length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header
     1242               field is present in a request and the "chunked" transfer-coding is not the final encoding, the message-body length cannot
     1243               be determined reliably; the server <em class="bcp14">MUST</em> respond with the 400 (Bad Request) status code and then close the connection.
    12391244            </p>
    12401245            <p>If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the Transfer-Encoding
     
    12431248               is decoded.
    12441249            </p>
    1245             <p>If a Transfer-Encoding header field is present in a response and the "chunked" transfer-coding is not present, the message-body
    1246                length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header field is present
    1247                in a request and the "chunked" transfer-coding is not the final encoding, the message-body length cannot be determined reliably;
    1248                the server <em class="bcp14">MUST</em> respond with 400 (Bad Request) and then close the connection.
    1249             </p>
    12501250         </li>
    12511251         <li>
    1252             <p>If a valid Content-Length header field (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section&nbsp;9.2</a>) is present without Transfer-Encoding, its decimal value in octets defines the message-body length. If the actual number
    1253                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
    1254                the message is less 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 on a connection
    1255                and the connection has been closed by the server.
    1256             </p>
    1257             <p>If a message is received with multiple Content-Length header fields or a Content-Length header field with an invalid value,
    1258                the message framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code and then close the connection. If this is a response message received by a proxy
     1252            <p>If a message is received without Transfer-Encoding and with either multiple Content-Length header fields or a single Content-Length
     1253               header field with an invalid value, then the message framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code and then close the connection. If this is a response message received by a proxy
    12591254               or gateway, the proxy or gateway <em class="bcp14">MUST</em> discard the received response, send a 502 (Bad Gateway) status code as its downstream response, and then close the connection.
    12601255               If this is a response message received by a user-agent, the message-body length is determined by reading the connection until
     
    12631258         </li>
    12641259         <li>
     1260            <p>If a valid Content-Length header field (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section&nbsp;9.2</a>) is present without Transfer-Encoding, its decimal value defines the message-body length in octets. If the actual number
     1261               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
     1262               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 on a connection
     1263               and the connection has been closed by the server.
     1264            </p>
     1265         </li>
     1266         <li>
    12651267            <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>
    12661268         </li>
     
    12881290         number of octets or by failure to decode a transfer-encoded message-body, <em class="bcp14">MUST</em> be recorded as incomplete. 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
    12891291         error occurred). Cache requirements for incomplete responses are defined in <a href="p6-cache.html#errors.or.incomplete.response.cache.behavior" title="Storing Partial and Incomplete Responses">Section 2.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
     1292      </p>
     1293      <p id="rfc.section.3.3.p.14">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
     1294         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
     1295         requests on a connection is described in <a href="#pipelining" title="Pipelining">Section&nbsp;7.1.2.2</a>.
    12901296      </p>
    12911297      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="general.header.fields" href="#general.header.fields">General Header Fields</a></h2>
Note: See TracChangeset for help on using the changeset viewer.