Ignore:
Timestamp:
Dec 7, 2012, 11:34:43 PM (7 years ago)
Author:
fielding@…
Message:

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

File:
1 edited

Legend:

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

    r2034 r2036  
    17171717     If a valid <x:ref>Content-Length</x:ref> header field is present without
    17181718     <x:ref>Transfer-Encoding</x:ref>, its decimal value defines the
    1719      message body length in octets.  If the actual number of octets sent in
    1720      the message is less than the indicated Content-Length, the recipient
    1721      &MUST; consider the message to be incomplete and treat the connection
    1722      as no longer usable.
    1723      If the actual number of octets sent in the message is more than the indicated
    1724      Content-Length, the recipient &MUST; only process the message body up to the
    1725      field value's number of octets; the remainder of the message &MUST; either
    1726      be discarded or treated as the next message in a pipeline.  For the sake of
    1727      robustness, a user agent &MAY; attempt to detect and correct such an error
    1728      in message framing if it is parsing the response to the last request on
    1729      a connection and the connection has been closed by the server.
     1719     expected message body length in octets.
     1720     If the sender closes the connection or the recipient times out before the
     1721     indicated number of octets are received, the recipient &MUST; consider
     1722     the message to be incomplete and close the connection.
    17301723    </t></x:lt>
    17311724    <x:lt><t>
     
    17691762   the form of specific user configuration or by remembering the version of a
    17701763   prior received response.
     1764</t>
     1765<t>
     1766   If the final response to the last request on a connection has been
     1767   completely received and there remains additional data to read, a user agent
     1768   &MAY; discard the remaining data or attempt to determine if that data
     1769   belongs as part of the prior response body, which might be the case if the
     1770   prior message's Content-Length value is incorrect. A client &MUST-NOT;
     1771   process, cache, or forward such extra data as a separate response, since
     1772   such behavior would be vulnerable to cache poisoning.
    17711773</t>
    17721774</section>
Note: See TracChangeset for help on using the changeset viewer.