Changeset 957 for draft-ietf-httpbis


Ignore:
Timestamp:
28/07/10 03:04:03 (10 years ago)
Author:
fielding@…
Message:

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

Location:
draft-ietf-httpbis/latest
Files:
6 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>

  • 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>

  • draft-ietf-httpbis/latest/p3-payload.html

    r942 r957  
    401401      <meta name="dct.creator" content="Reschke, J. F.">
    402402      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    403       <meta name="dct.issued" scheme="ISO8601" content="2010-07-26">
     403      <meta name="dct.issued" scheme="ISO8601" content="2010-07-27">
    404404      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    405405      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
    … …  
    427427            </tr>
    428428            <tr>
    429                <td class="left">Expires: January 27, 2011</td>
     429               <td class="left">Expires: January 28, 2011</td>
    430430               <td class="right">J. Mogul</td>
    431431            </tr>
    … …  
    484484            <tr>
    485485               <td class="left"></td>
    486                <td class="right">July 26, 2010</td>
     486               <td class="right">July 27, 2010</td>
    487487            </tr>
    488488         </tbody>
    … …  
    510510         in progress”.
    511511      </p>
    512       <p>This Internet-Draft will expire in January 27, 2011.</p>
     512      <p>This Internet-Draft will expire in January 28, 2011.</p>
    513513      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    514514      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

  • draft-ietf-httpbis/latest/p4-conditional.html

    r928 r957  
    400400      <meta name="dct.creator" content="Reschke, J. F.">
    401401      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    402       <meta name="dct.issued" scheme="ISO8601" content="2010-07-24">
     402      <meta name="dct.issued" scheme="ISO8601" content="2010-07-27">
    403403      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    404404      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
    … …  
    426426            </tr>
    427427            <tr>
    428                <td class="left">Expires: January 25, 2011</td>
     428               <td class="left">Expires: January 28, 2011</td>
    429429               <td class="right">J. Mogul</td>
    430430            </tr>
    … …  
    483483            <tr>
    484484               <td class="left"></td>
    485                <td class="right">July 24, 2010</td>
     485               <td class="right">July 27, 2010</td>
    486486            </tr>
    487487         </tbody>
    … …  
    509509         in progress”.
    510510      </p>
    511       <p>This Internet-Draft will expire in January 25, 2011.</p>
     511      <p>This Internet-Draft will expire in January 28, 2011.</p>
    512512      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    513513      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

  • draft-ietf-httpbis/latest/p5-range.html

    r931 r957  
    400400      <meta name="dct.creator" content="Reschke, J. F.">
    401401      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    402       <meta name="dct.issued" scheme="ISO8601" content="2010-07-24">
     402      <meta name="dct.issued" scheme="ISO8601" content="2010-07-27">
    403403      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    404404      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests.">
    … …  
    426426            </tr>
    427427            <tr>
    428                <td class="left">Expires: January 25, 2011</td>
     428               <td class="left">Expires: January 28, 2011</td>
    429429               <td class="right">J. Mogul</td>
    430430            </tr>
    … …  
    483483            <tr>
    484484               <td class="left"></td>
    485                <td class="right">July 24, 2010</td>
     485               <td class="right">July 27, 2010</td>
    486486            </tr>
    487487         </tbody>
    … …  
    509509         in progress”.
    510510      </p>
    511       <p>This Internet-Draft will expire in January 25, 2011.</p>
     511      <p>This Internet-Draft will expire in January 28, 2011.</p>
    512512      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    513513      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>

  • draft-ietf-httpbis/latest/p7-auth.html

    r923 r957  
    393393      <meta name="dct.creator" content="Reschke, J. F.">
    394394      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    395       <meta name="dct.issued" scheme="ISO8601" content="2010-07-24">
     395      <meta name="dct.issued" scheme="ISO8601" content="2010-07-27">
    396396      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    397397      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication.">
    … …  
    424424            </tr>
    425425            <tr>
    426                <td class="left">Expires: January 25, 2011</td>
     426               <td class="left">Expires: January 28, 2011</td>
    427427               <td class="right">HP</td>
    428428            </tr>
    … …  
    477477            <tr>
    478478               <td class="left"></td>
    479                <td class="right">July 24, 2010</td>
     479               <td class="right">July 27, 2010</td>
    480480            </tr>
    481481         </tbody>
    … …  
    503503         in progress”.
    504504      </p>
    505       <p>This Internet-Draft will expire in January 25, 2011.</p>
     505      <p>This Internet-Draft will expire in January 28, 2011.</p>
    506506      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    507507      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
Note: See TracChangeset for help on using the changeset viewer.