Changeset 1156 for draft-ietf-httpbis
- Timestamp:
- 09/03/11 21:41:51 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1155 r1156 1271 1271 <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 1272 1272 </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 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 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 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 1274 1276 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 6.2</a>. 1275 1277 </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 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 1278 1285 in the request's header fields, even if the request method does not define any use for a message-body. This allows the request 1279 1286 message framing algorithm to be independent of method semantics. 1280 1287 </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 and1288 <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 1282 1289 the response status code (<a href="#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 5.1.1</a>). Responses to the HEAD request method never include a message-body because the associated response header fields (e.g., 1283 1290 Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the method had been GET. All 1xx 1284 1291 (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. 1285 1292 </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> 1288 1295 <ol> 1289 1296 <li> … … 1293 1300 </li> 1294 1301 <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 9.7</a>)is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding1302 <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding 1296 1303 indicates the data is complete. 1297 1304 </p> … … 1308 1315 </li> 1309 1316 <li> 1310 <p>If a message is received without Transfer-Encoding and with either multiple Content-Length header fields or a single Content-Length1311 header field withan 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 proxy1317 <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 1312 1319 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. 1314 1321 </p> 1315 1322 </li> 1316 1323 <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 9.2</a>) is present without Transfer-Encoding, its decimal value defines the message-body length in octets. If the actual number1318 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 in1324 <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 1319 1326 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 1320 1327 and the connection has been closed by the server. … … 1330 1337 </li> 1331 1338 </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 interrupted1339 <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 1333 1340 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 1334 1341 with HTTP/1.0. 1335 1342 </p> 1336 <p id="rfc.section.3.3.p.1 0">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.1 1">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, 1339 1346 since some existing services respond to "chunked" with a 411 (Length Required) status code even though they understand the 1340 1347 chunked encoding. This is typically because such services are implemented via a gateway that requires a content-length in 1341 1348 advance of being called and the server is unable or unwilling to buffer the entire request before processing. 1342 1349 </p> 1343 <p id="rfc.section.3.3.p.1 2">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; such1350 <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 1344 1351 knowledge can be in the form of specific user configuration or by remembering the version of a prior received response. 1345 1352 </p> 1346 <p id="rfc.section.3.3.p.1 3">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 expected1353 <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 1347 1354 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 1348 1355 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>. 1349 1356 </p> 1350 <p id="rfc.section.3.3.p.1 4">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 data1357 <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 1351 1358 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 1352 1359 requests on a connection is described in <a href="#pipelining" title="Pipelining">Section 7.1.2.2</a>. … … 1383 1390 <tr> 1384 1391 <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 9.7</a></td>1392 <td class="left"><a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 9.7</a></td> 1386 1393 </tr> 1387 1394 <tr> … … 1677 1684 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#rule.token.separators" class="smpl">token</a> 1678 1685 <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 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 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 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 9.7</a>). 1680 1687 </p> 1681 1688 <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 … … 2447 2454 <td class="left">http</td> 2448 2455 <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 9.7</a>2456 <td class="left"> <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section 9.7</a> 2450 2457 </td> 2451 2458 </tr> … … 3779 3786 <li>TE <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> 3780 3787 <li>Trailer <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 <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 <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> 3782 3789 <li>Upgrade <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> 3783 3790 <li>Via <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> … … 3935 3942 <li><em>Tou1998</em> <a href="#rfc.xref.Tou1998.1">7.1.1</a>, <a href="#Tou1998"><b>13.2</b></a></li> 3936 3943 <li>Trailer header field <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 <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 <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> 3938 3945 <li>transforming proxy <a href="#rfc.iref.t.1"><b>2.3</b></a></li> 3939 3946 <li>transparent proxy <a href="#rfc.iref.t.3"><b>2.3</b></a></li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1151 r1156 1356 1356 <t> 1357 1357 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. 1365 1383 </t> 1366 1384 <t> … … 1400 1418 </t></x:lt> 1401 1419 <x:lt><t> 1402 If a Transfer-Encoding header field (<xref target="header.transfer-encoding"/>)1403 is presentand 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"/>) 1404 1422 is the final encoding, the message-body length is determined by reading 1405 1423 and decoding the chunked data until the transfer-coding indicates the … … 1417 1435 </t> 1418 1436 <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. 1421 1440 Such a message might indicate an attempt to perform request or response 1422 1441 smuggling (bypass of security-related checks on message routing or content) … … 1427 1446 <x:lt><t> 1428 1447 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. 1432 1452 If this is a request message, the server &MUST; respond with 1433 1453 a 400 (Bad Request) status code and then close the connection. … … 1435 1455 or gateway &MUST; discard the received response, send a 502 (Bad Gateway) 1436 1456 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; be1457 If this is a response message received by a user-agent, it &MUST; be 1438 1458 treated as an error by discarding the message and closing the connection. 1439 1459 </t></x:lt> 1440 1460 <x:lt><t> 1441 If a valid Content-Length header field (<xref target="header.content-length"/>)1461 If a valid Content-Length header field 1442 1462 is present without Transfer-Encoding, its decimal value defines the 1443 1463 message-body length in octets. If the actual number of octets sent in
Note: See TracChangeset
for help on using the changeset viewer.