Changeset 957 for draft-ietf-httpbis/latest/p1-messaging.html

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:

• draft-ietf-httpbis/latest/p1-messaging.html (modified) (5 diffs)

draft-ietf-httpbis/latest/p1-messaging.html

@@ -1219 +1219 @@
       <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
          in the request's header fields, even if the request method does not define any use for a message-body. This allows the request
-         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.
+         message framing algorithm to be independent of method semantics.
       </p>
       <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
@@ -1235 +1235 @@
          </li>
          <li>
-            <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
-               the data is complete.
+            <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
+               indicates the data is complete.
+            </p>
+            <p>If a Transfer-Encoding header field is present in a response and the "chunked" transfer-coding is not the final encoding,
+               the message-body length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header
+               field is present in a request and the "chunked" transfer-coding is not the final encoding, the message-body length cannot
+               be determined reliably; the server <em class="bcp14">MUST</em> respond with the 400 (Bad Request) status code and then close the connection.
             </p>
             <p>If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the Transfer-Encoding
@@ -1243 +1248 @@
                is decoded.
             </p>
-            <p>If a Transfer-Encoding header field is present in a response and the "chunked" transfer-coding is not present, the message-body
-               length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header field is present
-               in a request and the "chunked" transfer-coding is not the final encoding, the message-body length cannot be determined reliably;
-               the server <em class="bcp14">MUST</em> respond with 400 (Bad Request) and then close the connection.
-            </p>
          </li>
          <li>
-            <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
-               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
-               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
-               and the connection has been closed by the server.
-            </p>
-            <p>If a message is received with multiple Content-Length header fields or a Content-Length header field with an invalid value,
-               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
+            <p>If a message is received without Transfer-Encoding and with either multiple Content-Length header fields or a single Content-Length
+               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
                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.
                If this is a response message received by a user-agent, the message-body length is determined by reading the connection until
@@ -1263 +1258 @@
          </li>
          <li>
+            <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
+               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
+               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
+               and the connection has been closed by the server.
+            </p>
+         </li>
+         <li>
             <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>
          </li>
@@ -1288 +1290 @@
          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
          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>.
+      </p>
+      <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
+         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
+         requests on a connection is described in <a href="#pipelining" title="Pipelining">Section&nbsp;7.1.2.2</a>.
       </p>
       <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>