Changeset 2036

Timestamp:

08/12/12 07:34:43 (9 years ago)

Author:

fielding@…

Message:

(editorial) improvements to message length definition; addresses #392

File:

• draft-ietf-httpbis/latest/p1-messaging.xml (modified) (2 diffs)

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

@@ -1717 +1717 @@
      If a valid <x:ref>Content-Length</x:ref> header field is present without
      <x:ref>Transfer-Encoding</x:ref>, 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
-     &MUST; 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 &MUST; only process the message body up to the
-     field value's number of octets; the remainder of the message &MUST; either
-     be discarded or treated as the next message in a pipeline.  For the sake of
-     robustness, a user agent &MAY; attempt to detect and correct such an error
-     in message framing if it is parsing the response to the last request on
-     a connection and the connection has been closed by the server.
+     expected message body length in octets.
+     If the sender closes the connection or the recipient times out before the
+     indicated number of octets are received, the recipient &MUST; consider
+     the message to be incomplete and close the connection.
     </t></x:lt>
     <x:lt><t>
@@ -1769 +1762 @@
    the form of specific user configuration or by remembering the version of a
    prior received response.
+</t>
+<t>
+   If the final response to the last request on a connection has been
+   completely received and there remains additional data to read, a user agent
+   &MAY; discard the remaining data or attempt to determine if that data
+   belongs as part of the prior response body, which might be the case if the
+   prior message's Content-Length value is incorrect. A client &MUST-NOT;
+   process, cache, or forward such extra data as a separate response, since
+   such behavior would be vulnerable to cache poisoning.
 </t>
 </section>