Changeset 1156 for draft-ietf-httpbis


Ignore:
Timestamp:
Mar 9, 2011, 1:41:51 PM (9 years ago)
Author:
fielding@…
Message:

Explicitly require that recipients fix duplicate received Content-Length
and correctly combine multiple Transfer-Encoding fields prior to
determining the message-body length. Require (MUST instead of SHOULD)
user agents to discard messages with framing errors that might indicate
response smuggling.

Addresses #95

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

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

    r1155 r1156  
    12711271      <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.44"></span>  <a href="#message.body" class="smpl">message-body</a> = *OCTET
    12721272</pre><p id="rfc.section.3.3.p.3">The message-body differs from the payload body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding
    1273          header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section&nbsp;9.7</a>). When one or more transfer-codings are applied to a payload in order to form the message-body, the Transfer-Encoding header
     1273         header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section&nbsp;9.7</a>). If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>, before determining the message-body length.
     1274      </p>
     1275      <p id="rfc.section.3.3.p.4">When one or more transfer-codings are applied to a payload in order to form the message-body, the Transfer-Encoding header
    12741276         field <em class="bcp14">MUST</em> contain the list of transfer-codings applied. Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain under the constraints found in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>.
    12751277      </p>
    1276       <p id="rfc.section.3.3.p.4">The rules for when a message-body is allowed in a message differ for requests and responses.</p>
    1277       <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
     1278      <p id="rfc.section.3.3.p.5">If a message is received that has multiple Content-Length header fields (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section&nbsp;9.2</a>) with field-values consisting of the same decimal value, or a single Content-Length header field with a field value containing
     1279         a list of identical decimal values (e.g., "Content-Length: 42, 42"), indicating that duplicate Content-Length header fields
     1280         have been generated or combined by an upstream message processor, then the recipient <em class="bcp14">MUST</em> replace the duplicated fields or field-values with a single valid Content-Length field containing that decimal value prior
     1281         to determining the message-body length.
     1282      </p>
     1283      <p id="rfc.section.3.3.p.6">The rules for when a message-body is allowed in a message differ for requests and responses.</p>
     1284      <p id="rfc.section.3.3.p.7">The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field
    12781285         in the request's header fields, even if the request method does not define any use for a message-body. This allows the request
    12791286         message framing algorithm to be independent of method semantics.
    12801287      </p>
    1281       <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
     1288      <p id="rfc.section.3.3.p.8">For response messages, whether or not a message-body is included with a message is dependent on both the request method and
    12821289         the response status code (<a href="#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section&nbsp;5.1.1</a>). Responses to the HEAD request method never include a message-body because the associated response header fields (e.g.,
    12831290         Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the method had been GET. All 1xx
    12841291         (Informational), 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message-body. All other responses do include a message-body, although the body <em class="bcp14">MAY</em> be of zero length.
    12851292      </p>
    1286       <p id="rfc.section.3.3.p.7">The length of the message-body is determined by one of the following (in order of precedence):</p>
    1287       <p id="rfc.section.3.3.p.8"> </p>
     1293      <p id="rfc.section.3.3.p.9">The length of the message-body is determined by one of the following (in order of precedence):</p>
     1294      <p id="rfc.section.3.3.p.10"> </p>
    12881295      <ol>
    12891296         <li>
    … …  
    12931300         </li>
    12941301         <li>
    1295             <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
     1302            <p>If a Transfer-Encoding header field 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
    12961303               indicates the data is complete.
    12971304            </p>
    … …  
    13081315         </li>
    13091316         <li>
    1310             <p>If a message is received without Transfer-Encoding and with either multiple Content-Length header fields or a single Content-Length
    1311                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
     1317            <p>If a message is received without Transfer-Encoding and with either multiple Content-Length header fields having differing
     1318               field-values or a single Content-Length header field having 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
    13121319               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.
    1313                If this is a response message received by a user-agent, it <em class="bcp14">SHOULD</em> be treated as an error by discarding the message and closing the connection.
     1320               If this is a response message received by a user-agent, it <em class="bcp14">MUST</em> be treated as an error by discarding the message and closing the connection.
    13141321            </p>
    13151322         </li>
    13161323         <li>
    1317             <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
    1318                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
     1324            <p>If a valid Content-Length header field is present without Transfer-Encoding, its decimal value defines the message-body length
     1325               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
    13191326               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
    13201327               and the connection has been closed by the server.
    … …  
    13301337         </li>
    13311338      </ol>
    1332       <p id="rfc.section.3.3.p.9">Since there is no way to distinguish a successfully completed, close-delimited message from a partially-received message interrupted
     1339      <p id="rfc.section.3.3.p.11">Since there is no way to distinguish a successfully completed, close-delimited message from a partially-received message interrupted
    13331340         by network failure, implementations <em class="bcp14">SHOULD</em> use encoding or length-delimited messages whenever possible. The close-delimiting feature exists primarily for backwards compatibility
    13341341         with HTTP/1.0.
    13351342      </p>
    1336       <p id="rfc.section.3.3.p.10">A server <em class="bcp14">MAY</em> reject a request that contains a message-body but not a Content-Length by responding with 411 (Length Required).
    1337       </p>
    1338       <p id="rfc.section.3.3.p.11">Unless a transfer-coding other than "chunked" has been applied, a client that sends a request containing a message-body <em class="bcp14">SHOULD</em> use a valid Content-Length header field if the message-body length is known in advance, rather than the "chunked" encoding,
     1343      <p id="rfc.section.3.3.p.12">A server <em class="bcp14">MAY</em> reject a request that contains a message-body but not a Content-Length by responding with 411 (Length Required).
     1344      </p>
     1345      <p id="rfc.section.3.3.p.13">Unless a transfer-coding other than "chunked" has been applied, a client that sends a request containing a message-body <em class="bcp14">SHOULD</em> use a valid Content-Length header field if the message-body length is known in advance, rather than the "chunked" encoding,
    13391346         since some existing services respond to "chunked" with a 411 (Length Required) status code even though they understand the
    13401347         chunked encoding. This is typically because such services are implemented via a gateway that requires a content-length in
    13411348         advance of being called and the server is unable or unwilling to buffer the entire request before processing.
    13421349      </p>
    1343       <p id="rfc.section.3.3.p.12">A client that sends a request containing a message-body <em class="bcp14">MUST</em> include a valid Content-Length header field if it does not know the server will handle HTTP/1.1 (or later) requests; such
     1350      <p id="rfc.section.3.3.p.14">A client that sends a request containing a message-body <em class="bcp14">MUST</em> include a valid Content-Length header field if it does not know the server will handle HTTP/1.1 (or later) requests; such
    13441351         knowledge can be in the form of specific user configuration or by remembering the version of a prior received response.
    13451352      </p>
    1346       <p id="rfc.section.3.3.p.13">Request messages that are prematurely terminated, possibly due to a cancelled connection or a server-imposed time-out exception, <em class="bcp14">MUST</em> result in closure of the connection; sending an HTTP/1.1 error response prior to closing the connection is <em class="bcp14">OPTIONAL</em>. Response messages that are prematurely terminated, usually by closure of the connection prior to receiving the expected
     1353      <p id="rfc.section.3.3.p.15">Request messages that are prematurely terminated, possibly due to a cancelled connection or a server-imposed time-out exception, <em class="bcp14">MUST</em> result in closure of the connection; sending an HTTP/1.1 error response prior to closing the connection is <em class="bcp14">OPTIONAL</em>. Response messages that are prematurely terminated, usually by closure of the connection prior to receiving the expected
    13471354         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
    13481355         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>.
    13491356      </p>
    1350       <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
     1357      <p id="rfc.section.3.3.p.16">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
    13511358         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
    13521359         requests on a connection is described in <a href="#pipelining" title="Pipelining">Section&nbsp;7.1.2.2</a>.
    … …  
    13831390               <tr>
    13841391                  <td class="left">Transfer-Encoding</td>
    1385                   <td class="left"><a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section&nbsp;9.7</a></td>
     1392                  <td class="left"><a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;9.7</a></td>
    13861393               </tr>
    13871394               <tr>
    … …  
    16771684  <a href="#rule.parameter" class="smpl">attribute</a>               = <a href="#rule.token.separators" class="smpl">token</a>
    16781685  <a href="#rule.parameter" class="smpl">value</a>                   = <a href="#rule.token.separators" class="smpl">word</a>
    1679 </pre><p id="rfc.section.6.2.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;9.5</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section&nbsp;9.7</a>).
     1686</pre><p id="rfc.section.6.2.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;9.5</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section&nbsp;9.7</a>).
    16801687      </p>
    16811688      <p id="rfc.section.6.2.p.6">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport
    … …  
    24472454                  <td class="left">http</td>
    24482455                  <td class="left">standard</td>
    2449                   <td class="left"> <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.5" title="Transfer-Encoding">Section&nbsp;9.7</a>
     2456                  <td class="left"> <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section&nbsp;9.7</a>
    24502457                  </td>
    24512458               </tr>
    … …  
    37793786                        <li>TE&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">6.2</a>, <a href="#rfc.xref.header.te.2">6.2.1</a>, <a href="#rfc.xref.header.te.3">6.4</a>, <a href="#rfc.iref.h.11"><b>9.5</b></a>, <a href="#rfc.xref.header.te.4">10.1</a></li>
    37803787                        <li>Trailer&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">3.4</a>, <a href="#rfc.xref.header.trailer.2">6.2.1</a>, <a href="#rfc.iref.h.12"><b>9.6</b></a>, <a href="#rfc.xref.header.trailer.3">10.1</a></li>
    3781                         <li>Transfer-Encoding&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.3">3.4</a>, <a href="#rfc.xref.header.transfer-encoding.4">6.2</a>, <a href="#rfc.iref.h.13"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.5">10.1</a></li>
     3788                        <li>Transfer-Encoding&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">3.4</a>, <a href="#rfc.xref.header.transfer-encoding.3">6.2</a>, <a href="#rfc.iref.h.13"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">10.1</a></li>
    37823789                        <li>Upgrade&nbsp;&nbsp;<a href="#rfc.xref.header.upgrade.1">3.4</a>, <a href="#rfc.iref.h.14"><b>9.8</b></a>, <a href="#rfc.xref.header.upgrade.2">10.1</a>, <a href="#rfc.xref.header.upgrade.3">B.3</a></li>
    37833790                        <li>Via&nbsp;&nbsp;<a href="#rfc.xref.header.via.1">3.4</a>, <a href="#rfc.iref.h.15"><b>9.9</b></a>, <a href="#rfc.xref.header.via.2">10.1</a></li>
    … …  
    39353942                  <li><em>Tou1998</em>&nbsp;&nbsp;<a href="#rfc.xref.Tou1998.1">7.1.1</a>, <a href="#Tou1998"><b>13.2</b></a></li>
    39363943                  <li>Trailer header field&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">3.4</a>, <a href="#rfc.xref.header.trailer.2">6.2.1</a>, <a href="#rfc.iref.t.6"><b>9.6</b></a>, <a href="#rfc.xref.header.trailer.3">10.1</a></li>
    3937                   <li>Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.3">3.4</a>, <a href="#rfc.xref.header.transfer-encoding.4">6.2</a>, <a href="#rfc.iref.t.7"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.5">10.1</a></li>
     3944                  <li>Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.xref.header.transfer-encoding.2">3.4</a>, <a href="#rfc.xref.header.transfer-encoding.3">6.2</a>, <a href="#rfc.iref.t.7"><b>9.7</b></a>, <a href="#rfc.xref.header.transfer-encoding.4">10.1</a></li>
    39383945                  <li>transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>2.3</b></a></li>
    39393946                  <li>transparent proxy&nbsp;&nbsp;<a href="#rfc.iref.t.3"><b>2.3</b></a></li>

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

    r1151 r1156  
    13561356<t>
    13571357   The message-body differs from the payload body only when a transfer-coding
    1358    has been applied, as indicated by the Transfer-Encoding header field (<xref target="header.transfer-encoding"/>).  When one or more transfer-codings are
    1359    applied to a payload in order to form the message-body, the
    1360    Transfer-Encoding header field &MUST; contain the list of
    1361    transfer-codings applied. Transfer-Encoding is a property of the message,
    1362    not of the payload, and thus &MAY; be added or removed by any implementation
    1363    along the request/response chain under the constraints found in
    1364    <xref target="transfer.codings"/>.
     1358   has been applied, as indicated by the Transfer-Encoding header field
     1359   (<xref target="header.transfer-encoding"/>).  If more than one
     1360   Transfer-Encoding header field is present in a message, the multiple
     1361   field-values &MUST; be combined into one field-value, according to the
     1362   algorithm defined in <xref target="header.fields"/>, before determining
     1363   the message-body length.
     1364</t>
     1365<t>
     1366   When one or more transfer-codings are applied to a payload in order to
     1367   form the message-body, the Transfer-Encoding header field &MUST; contain
     1368   the list of transfer-codings applied. Transfer-Encoding is a property of
     1369   the message, not of the payload, and thus &MAY; be added or removed by
     1370   any implementation along the request/response chain under the constraints
     1371   found in <xref target="transfer.codings"/>.
     1372</t>
     1373<t>
     1374   If a message is received that has multiple Content-Length header fields
     1375   (<xref target="header.content-length"/>) with field-values consisting
     1376   of the same decimal value, or a single Content-Length header field with
     1377   a field value containing a list of identical decimal values (e.g.,
     1378   "Content-Length: 42, 42"), indicating that duplicate Content-Length
     1379   header fields have been generated or combined by an upstream message
     1380   processor, then the recipient &MUST; replace the duplicated fields or
     1381   field-values with a single valid Content-Length field containing that
     1382   decimal value prior to determining the message-body length.
    13651383</t>
    13661384<t>
    … …  
    14001418    </t></x:lt>
    14011419    <x:lt><t>
    1402      If a Transfer-Encoding header field (<xref target="header.transfer-encoding"/>)
    1403      is present and the "chunked" transfer-coding (<xref target="transfer.codings"/>)
     1420     If a Transfer-Encoding header field is present
     1421     and the "chunked" transfer-coding (<xref target="transfer.codings"/>)
    14041422     is the final encoding, the message-body length is determined by reading
    14051423     and decoding the chunked data until the transfer-coding indicates the
    … …  
    14171435    </t>
    14181436    <t>
    1419      If a message is received with both a Transfer-Encoding header field and a
    1420      Content-Length header field, the Transfer-Encoding overrides the Content-Length.
     1437     If a message is received with both a Transfer-Encoding header field
     1438     and a Content-Length header field, the Transfer-Encoding overrides
     1439     the Content-Length.
    14211440     Such a message might indicate an attempt to perform request or response
    14221441     smuggling (bypass of security-related checks on message routing or content)
    … …  
    14271446    <x:lt><t>
    14281447     If a message is received without Transfer-Encoding and with either
    1429      multiple Content-Length header fields or a single Content-Length header
    1430      field with an invalid value, then the message framing is invalid and
    1431      &MUST; be treated as an error to prevent request or response smuggling.
     1448     multiple Content-Length header fields having differing field-values or
     1449     a single Content-Length header field having an invalid value, then the
     1450     message framing is invalid and &MUST; be treated as an error to
     1451     prevent request or response smuggling.
    14321452     If this is a request message, the server &MUST; respond with
    14331453     a 400 (Bad Request) status code and then close the connection.
    … …  
    14351455     or gateway &MUST; discard the received response, send a 502 (Bad Gateway)
    14361456     status code as its downstream response, and then close the connection.
    1437      If this is a response message received by a user-agent, it &SHOULD; be
     1457     If this is a response message received by a user-agent, it &MUST; be
    14381458     treated as an error by discarding the message and closing the connection.
    14391459    </t></x:lt>
    14401460    <x:lt><t>
    1441      If a valid Content-Length header field (<xref target="header.content-length"/>)
     1461     If a valid Content-Length header field
    14421462     is present without Transfer-Encoding, its decimal value defines the
    14431463     message-body length in octets.  If the actual number of octets sent in
Note: See TracChangeset for help on using the changeset viewer.