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.xml

    r953 r957  
    12761276   define any use for a message-body.  This allows the request
    12771277   message framing algorithm to be independent of method semantics.
    1278    A server &MUST; read the entire request message-body or close
    1279    the connection after sending its response.
    12801278</t>
    12811279<t>
     
    13061304     If a Transfer-Encoding header field (<xref target="header.transfer-encoding"/>)
    13071305     is present and the "chunked" transfer-coding (<xref target="transfer.codings"/>)
    1308      is used, the message-body length is determined by reading and decoding the
    1309      chunked data until the transfer-coding indicates the data is complete.
     1306     is the final encoding, the message-body length is determined by reading
     1307     and decoding the chunked data until the transfer-coding indicates the
     1308     data is complete.
     1309    </t>
     1310    <t>
     1311     If a Transfer-Encoding header field is present in a response and the
     1312     "chunked" transfer-coding is not the final encoding, the message-body
     1313     length is determined by reading the connection until it is closed by
     1314     the server.
     1315     If a Transfer-Encoding header field is present in a request and the
     1316     "chunked" transfer-coding is not the final encoding, the message-body
     1317     length cannot be determined reliably; the server &MUST; respond with
     1318     the 400 (Bad Request) status code and then close the connection.
    13101319    </t>
    13111320    <t>
     
    13171326     be removed, prior to forwarding the message downstream, or replaced with
    13181327     the real message-body length after the transfer-coding is decoded.
    1319     </t>
    1320     <t>
    1321      If a Transfer-Encoding header field is present in a response and the
    1322      "chunked" transfer-coding is not present, the message-body length is
    1323      determined by reading the connection until it is closed by the server.
    1324      If a Transfer-Encoding header field is present in a request and the
    1325      "chunked" transfer-coding is not the final encoding, the message-body
    1326      length cannot be determined reliably; the server &MUST; respond with
    1327      400 (Bad Request) and then close the connection.
    13281328    </t></x:lt>
    13291329    <x:lt><t>
    1330      If a valid Content-Length header field (<xref target="header.content-length"/>)
    1331      is present without Transfer-Encoding, its decimal value in octets defines
    1332      the message-body length.  If the actual number of octets sent in the message
    1333      is less than the indicated Content-Length, the recipient &MUST; consider
    1334      the message to be incomplete and treat the connection as no longer usable.
    1335      If the actual number of octets sent in the message is less than the indicated
    1336      Content-Length, the recipient &MUST; only process the message-body up to the
    1337      field value's number of octets; the remainder of the message &MUST; either
    1338      be discarded or treated as the next message in a pipeline.  For the sake of
    1339      robustness, a user-agent &MAY; attempt to detect and correct such an error
    1340      in message framing if it is parsing the response to the last request on
    1341      on a connection and the connection has been closed by the server.
    1342     </t>
    1343     <t>
    1344      If a message is received with multiple Content-Length header fields or a
    1345      Content-Length header field with an invalid value, the message framing
    1346      is invalid and &MUST; be treated as an error to prevent request or
    1347      response smuggling.
     1330     If a message is received without Transfer-Encoding and with either
     1331     multiple Content-Length header fields or a single Content-Length header
     1332     field with an invalid value, then the message framing is invalid and
     1333     &MUST; be treated as an error to prevent request or response smuggling.
    13481334     If this is a request message, the server &MUST; respond with
    13491335     a 400 (Bad Request) status code and then close the connection.
     
    13541340     length is determined by reading the connection until it is closed;
    13551341     an error &SHOULD; be indicated to the user.
     1342    </t></x:lt>
     1343    <x:lt><t>
     1344     If a valid Content-Length header field (<xref target="header.content-length"/>)
     1345     is present without Transfer-Encoding, its decimal value defines the
     1346     message-body length in octets.  If the actual number of octets sent in
     1347     the message is less than the indicated Content-Length, the recipient
     1348     &MUST; consider the message to be incomplete and treat the connection
     1349     as no longer usable.
     1350     If the actual number of octets sent in the message is more than the indicated
     1351     Content-Length, the recipient &MUST; only process the message-body up to the
     1352     field value's number of octets; the remainder of the message &MUST; either
     1353     be discarded or treated as the next message in a pipeline.  For the sake of
     1354     robustness, a user-agent &MAY; attempt to detect and correct such an error
     1355     in message framing if it is parsing the response to the last request on
     1356     on a connection and the connection has been closed by the server.
    13561357    </t></x:lt>
    13571358    <x:lt><t>
     
    14071408   to the user that an error occurred).  Cache requirements for incomplete
    14081409   responses are defined in &cache-incomplete;.
     1410</t>
     1411<t>
     1412   A server &MUST; read the entire request message-body or close
     1413   the connection after sending its response, since otherwise the
     1414   remaining data on a persistent connection would be misinterpreted
     1415   as the next request.  Likewise,
     1416   a client &MUST; read the entire response message-body if it intends
     1417   to reuse the same connection for a subsequent request.  Pipelining
     1418   multiple requests on a connection is described in <xref target="pipelining"/>.
    14091419</t>
    14101420</section>
Note: See TracChangeset for help on using the changeset viewer.