Changeset 1540 for draft-ietf-httpbis/latest
- Timestamp:
- 20/02/12 09:10:22 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1539 r1540 460 460 } 461 461 @bottom-center { 462 content: "Expires August 2 2, 2012";462 content: "Expires August 23, 2012"; 463 463 } 464 464 @bottom-right { … … 510 510 <meta name="dct.creator" content="Reschke, J. F."> 511 511 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 512 <meta name="dct.issued" scheme="ISO8601" content="2012-02- 19">512 <meta name="dct.issued" scheme="ISO8601" content="2012-02-20"> 513 513 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 514 514 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 542 542 </tr> 543 543 <tr> 544 <td class="left">Expires: August 2 2, 2012</td>544 <td class="left">Expires: August 23, 2012</td> 545 545 <td class="right">HP</td> 546 546 </tr> … … 595 595 <tr> 596 596 <td class="left"></td> 597 <td class="right">February 19, 2012</td>597 <td class="right">February 20, 2012</td> 598 598 </tr> 599 599 </tbody> … … 628 628 in progress”. 629 629 </p> 630 <p>This Internet-Draft will expire on August 2 2, 2012.</p>630 <p>This Internet-Draft will expire on August 23, 2012.</p> 631 631 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 632 632 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 702 702 <li>4.2 <a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li> 703 703 <li>4.3 <a href="#effective.request.uri">Effective Request URI</a></li> 704 <li>4.4 <a href="#associating.re quest.response">Associating Response toRequest</a></li>704 <li>4.4 <a href="#associating.response.to.request">Associating a Response to a Request</a></li> 705 705 </ul> 706 706 </li> … … 1452 1452 </p> 1453 1453 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="message.body" href="#message.body">Message Body</a></h2> 1454 <p id="rfc.section.3.3.p.1">The message-body (if any) of an HTTP message is used to carry the payload body associated with the request or response.</p> 1454 <p id="rfc.section.3.3.p.1">The message body (if any) of an HTTP message is used to carry the payload body of that request or response. The message body 1455 is identical to the payload body unless a transfer coding has been applied, as described in <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 3.3.1</a>. 1456 </p> 1455 1457 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.51"></span> <a href="#message.body" class="smpl">message-body</a> = *OCTET 1456 </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 1457 header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section 3.3.1</a>). 1458 </p> 1459 <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> 1460 <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 1461 in the request's header fields, even if the request method does not define any use for a message-body. This allows the request 1462 message framing algorithm to be independent of method semantics. 1463 </p> 1464 <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 1465 the response status code (<a href="#status.code" title="Status Code">Section 3.1.2.1</a>). Responses to the HEAD request method never include a message-body because the associated response header fields (e.g., 1458 </pre><p id="rfc.section.3.3.p.3">The rules for when a message body is allowed in a message differ for requests and responses.</p> 1459 <p id="rfc.section.3.3.p.4">The presence of a message body in a request is signaled by a a Content-Length or Transfer-Encoding header field. Request message 1460 framing is independent of method semantics, even if the method does not define any use for a message body. 1461 </p> 1462 <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response 1463 status code (<a href="#status.code" title="Status Code">Section 3.1.2.1</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., 1466 1464 Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET. 1467 All 1xx (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.1465 All 1xx (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. 1468 1466 </p> 1469 1467 <div id="rfc.iref.t.4"></div> 1470 1468 <div id="rfc.iref.h.6"></div> 1471 1469 <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a> <a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h3> 1472 <p id="rfc.section.3.3.1.p.1"> The "Transfer-Encoding" header field indicates what transfer-codings (if any) have been applied to the message body. It differs1473 f rom Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings1474 are not.1470 <p id="rfc.section.3.3.1.p.1">When one or more transfer encodings are applied to a payload body in order to form the message-body, a Transfer-Encoding header 1471 field <em class="bcp14">MUST</em> be sent in the message and <em class="bcp14">MUST</em> contain the list of corresponding transfer-coding names in the same order that they were applied. Transfer encodings are defined 1472 in <a href="#transfer.codings" title="Transfer Codings">Section 5</a>. 1475 1473 </p> 1476 1474 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.52"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> 1477 </pre><p id="rfc.section.3.3.1.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section 5</a>. An example is: 1478 </p> 1475 </pre><p id="rfc.section.3.3.1.p.3">Transfer-Encoding is analogous to the Content-Transfer-Encoding field of MIME, which was designed to enable safe transport 1476 of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="http://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP's case, Transfer-Encoding is 1477 primarily intended to accurately delimit a dynamically generated payload and to distinguish payload encodings that are only 1478 applied for transport efficiency or security from those that are characteristics of the target resource. 1479 </p> 1480 <p id="rfc.section.3.3.1.p.4">The "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1</a>) <em class="bcp14">MUST</em> be implemented by all HTTP/1.1 recipients because it plays a crucial role in delimiting messages when the payload body size 1481 is not known in advance. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message body and <em class="bcp14">MUST NOT</em> be applied more than once in a message-body. If any transfer-coding is applied to a request payload body, the final transfer-coding 1482 applied <em class="bcp14">MUST</em> be "chunked". If any transfer-coding is applied to a response payload body, then either the final transfer-coding applied <em class="bcp14">MUST</em> be "chunked" or the message <em class="bcp14">MUST</em> be terminated by closing the connection. 1483 </p> 1484 <p id="rfc.section.3.3.1.p.5">For example,</p> 1479 1485 <div id="rfc.figure.u.35"></div><pre class="text"> Transfer-Encoding: chunked 1480 </pre><p id="rfc.section.3.3.1.p.5">If multiple encodings have been applied to a representation, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. 1481 </p> 1482 <p id="rfc.section.3.3.1.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header field.</p> 1483 <p id="rfc.section.3.3.1.p.7">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. 1484 </p> 1485 <p id="rfc.section.3.3.1.p.8">When one or more transfer-codings are applied to a payload in order to form the message-body, the Transfer-Encoding header 1486 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 5</a>. 1486 </pre><p id="rfc.section.3.3.1.p.7">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. 1487 </p> 1488 <p id="rfc.section.3.3.1.p.8">Unlike Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), 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. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. 1489 </p> 1490 <p id="rfc.section.3.3.1.p.9">Transfer-Encoding was added in HTTP/1.1. It is generally assumed that implementations advertising only HTTP/1.0 support will 1491 not understand how to process a transfer-encoded payload. A client <em class="bcp14">MUST NOT</em> send a request containing Transfer-Encoding unless it knows the server will handle HTTP/1.1 (or later) requests; such knowledge 1492 might be in the form of specific user configuration or by remembering the version of a prior received response. A server <em class="bcp14">MUST NOT</em> send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1 (or later). 1493 </p> 1494 <p id="rfc.section.3.3.1.p.10">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection. 1487 1495 </p> 1488 1496 <div id="rfc.iref.c.6"></div> … … 1511 1519 </p> 1512 1520 <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a> <a id="message.body.length" href="#message.body.length">Message Body Length</a></h3> 1513 <p id="rfc.section.3.3.3.p.1">The length of themessage-body is determined by one of the following (in order of precedence):</p>1521 <p id="rfc.section.3.3.3.p.1">The length of a message-body is determined by one of the following (in order of precedence):</p> 1514 1522 <p id="rfc.section.3.3.3.p.2"> </p> 1515 1523 <ol> … … 1520 1528 </li> 1521 1529 <li> 1522 <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="# transfer.codings" title="Transfer Codings">Section 5</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding1530 <p>If a Transfer-Encoding header field is present and the "chunked" transfer-coding (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1</a>) is the final encoding, the message-body length is determined by reading and decoding the chunked data until the transfer-coding 1523 1531 indicates the data is complete. 1524 1532 </p> … … 1724 1732 <p id="rfc.section.4.3.p.9">Effective request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section 2.7.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/". 1725 1733 </p> 1726 <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="associating.re quest.response" href="#associating.request.response">Associating Response toRequest</a></h2>1734 <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2> 1727 1735 <p id="rfc.section.4.4.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response 1728 1736 messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made … … 1750 1758 <a href="#rule.parameter" class="smpl">value</a> = <a href="#rule.token.separators" class="smpl">word</a> 1751 1759 </pre><p id="rfc.section.5.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 5.4</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 3.3.1</a>). 1752 </p>1753 <p id="rfc.section.5.p.6">Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME, which were designed to enable safe transport1754 of binary data over a 7-bit transport service (<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>, <a href="http://tools.ietf.org/html/rfc2045#section-6">Section 6</a>). However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic1755 of message-bodies is the difficulty in determining the exact message body length (<a href="#message.body" title="Message Body">Section 3.3</a>), or the desire to encrypt data over a shared transport.1756 </p>1757 <p id="rfc.section.5.p.7">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection. A server <em class="bcp14">MUST NOT</em> send transfer-codings to an HTTP/1.0 client.1758 1760 </p> 1759 1761 <div id="rfc.iref.c.7"></div> … … 1825 1827 </p> 1826 1828 <p id="rfc.section.5.1.p.10">Use of chunk-ext extensions by senders is deprecated; they <em class="bcp14">SHOULD NOT</em> be sent and definition of new chunk-extensions is discouraged. 1827 </p>1828 <p id="rfc.section.5.1.p.11">Since "chunked" is the only transfer-coding required to be understood by HTTP/1.1 recipients, it plays a crucial role in delimiting1829 messages on a persistent connection. Whenever a transfer-coding is applied to a payload body in a request, the final transfer-coding1830 applied <em class="bcp14">MUST</em> be "chunked". If a transfer-coding is applied to a response payload body, then either the final transfer-coding applied <em class="bcp14">MUST</em> be "chunked" or the message <em class="bcp14">MUST</em> be terminated by closing the connection. When the "chunked" transfer-coding is used, it <em class="bcp14">MUST</em> be the last transfer-coding applied to form the message-body. The "chunked" transfer-coding <em class="bcp14">MUST NOT</em> be applied more than once in a message-body.1831 1829 </p> 1832 1830 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="compression.codings" href="#compression.codings">Compression Codings</a></h2> … … 3848 3846 <li><em>RFC1951</em> <a href="#rfc.xref.RFC1951.1">5.2.2</a>, <a href="#rfc.xref.RFC1951.2">9.4</a>, <a href="#RFC1951"><b>12.1</b></a></li> 3849 3847 <li><em>RFC1952</em> <a href="#rfc.xref.RFC1952.1">5.2.3</a>, <a href="#rfc.xref.RFC1952.2">9.4</a>, <a href="#RFC1952"><b>12.1</b></a></li> 3850 <li><em>RFC2045</em> <a href="#rfc.xref.RFC2045.1">1</a>, <a href="#rfc.xref.RFC2045.2"> 5</a>, <a href="#RFC2045"><b>12.2</b></a><ul>3851 <li><em>Section 6</em> <a href="#rfc.xref.RFC2045.2"> 5</a></li>3848 <li><em>RFC2045</em> <a href="#rfc.xref.RFC2045.1">1</a>, <a href="#rfc.xref.RFC2045.2">3.3.1</a>, <a href="#RFC2045"><b>12.2</b></a><ul> 3849 <li><em>Section 6</em> <a href="#rfc.xref.RFC2045.2">3.3.1</a></li> 3852 3850 </ul> 3853 3851 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1538 r1540 1550 1550 <x:anchor-alias value="message-body"/> 1551 1551 <t> 1552 The message-body (if any) of an HTTP message is used to carry the 1553 payload body associated with the request or response. 1552 The message body (if any) of an HTTP message is used to carry the 1553 payload body of that request or response. The message body is 1554 identical to the payload body unless a transfer coding has been 1555 applied, as described in <xref target="header.transfer-encoding"/>. 1554 1556 </t> 1555 1557 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="message-body"/> … … 1557 1559 </artwork></figure> 1558 1560 <t> 1559 The message-body differs from the payload body only when a transfer-coding 1560 has been applied, as indicated by the Transfer-Encoding header field 1561 (<xref target="header.transfer-encoding"/>). 1562 </t> 1563 <t> 1564 The rules for when a message-body is allowed in a message differ for 1561 The rules for when a message body is allowed in a message differ for 1565 1562 requests and responses. 1566 1563 </t> 1567 1564 <t> 1568 The presence of a message-body in a request is signaled by the 1569 inclusion of a Content-Length or Transfer-Encoding header field in 1570 the request's header fields, even if the request method does not 1571 define any use for a message-body. This allows the request 1572 message framing algorithm to be independent of method semantics. 1573 </t> 1574 <t> 1575 For response messages, whether or not a message-body is included with 1576 a message is dependent on both the request method and the response 1565 The presence of a message body in a request is signaled by a 1566 a Content-Length or Transfer-Encoding header field. 1567 Request message framing is independent of method semantics, 1568 even if the method does not define any use for a message body. 1569 </t> 1570 <t> 1571 The presence of a message body in a response depends on both 1572 the request method to which it is responding and the response 1577 1573 status code (<xref target="status.code"/>). 1578 Responses to the HEAD request method never include a message -body1574 Responses to the HEAD request method never include a message body 1579 1575 because the associated response header fields (e.g., Transfer-Encoding, 1580 1576 Content-Length, etc.) only indicate what their values would have been 1581 if the request method had been GET. All 1xx (Informational), 204 (No Content), 1582 and 304 (Not Modified) responses &MUST-NOT; include a message-body. 1577 if the request method had been GET. 1578 All 1xx (Informational), 204 (No Content), and 304 (Not Modified) 1579 responses &MUST-NOT; include a message body. 1583 1580 All other responses do include a message-body, although the body 1584 1581 &MAY; be of zero length. … … 1590 1587 <x:anchor-alias value="Transfer-Encoding"/> 1591 1588 <t> 1592 The "Transfer-Encoding" header field indicates what transfer-codings1593 (if any) have been applied to the message body. It differs from1594 Content-Encoding (&content-codings;) in that transfer-codings are a property1595 of the message (and therefore are removed by intermediaries), whereas1596 content-codings are not.1589 When one or more transfer encodings are applied to a payload body in order 1590 to form the message-body, a Transfer-Encoding header field &MUST; be sent 1591 in the message and &MUST; contain the list of corresponding 1592 transfer-coding names in the same order that they were applied. 1593 Transfer encodings are defined in <xref target="transfer.codings"/>. 1597 1594 </t> 1598 1595 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/> … … 1600 1597 </artwork></figure> 1601 1598 <t> 1602 Transfer-codings are defined in <xref target="transfer.codings"/>. An example is: 1599 Transfer-Encoding is analogous to the Content-Transfer-Encoding field of 1600 MIME, which was designed to enable safe transport of binary data over a 1601 7-bit transport service (<xref target="RFC2045" x:fmt="," x:sec="6"/>). 1602 However, safe transport has a different focus for an 8bit-clean transfer 1603 protocol. In HTTP's case, Transfer-Encoding is primarily intended to 1604 accurately delimit a dynamically generated payload and to distinguish 1605 payload encodings that are only applied for transport efficiency or 1606 security from those that are characteristics of the target resource. 1607 </t> 1608 <t> 1609 The "chunked" transfer-coding (<xref target="chunked.encoding"/>) 1610 &MUST; be implemented by all HTTP/1.1 recipients because it plays a 1611 crucial role in delimiting messages when the payload body size is not 1612 known in advance. 1613 When the "chunked" transfer-coding is used, it &MUST; be the last 1614 transfer-coding applied to form the message body and &MUST-NOT; 1615 be applied more than once in a message-body. 1616 If any transfer-coding is applied to a request payload body, 1617 the final transfer-coding applied &MUST; be "chunked". 1618 If any transfer-coding is applied to a response payload body, then either 1619 the final transfer-coding applied &MUST; be "chunked" or 1620 the message &MUST; be terminated by closing the connection. 1621 </t> 1622 <t> 1623 For example, 1603 1624 </t> 1604 1625 <figure><artwork type="example"> … … 1606 1627 </artwork></figure> 1607 1628 <t> 1608 If multiple encodings have been applied to a representation, the transfer-codings 1609 &MUST; be listed in the order in which they were applied. 1629 If more than one Transfer-Encoding header field is present in a message, 1630 the multiple field-values &MUST; be combined into one field-value, 1631 according to the algorithm defined in <xref target="header.fields"/>, 1632 before determining the message-body length. 1633 </t> 1634 <t> 1635 Unlike Content-Encoding (&content-codings;), Transfer-Encoding is a 1636 property of the message, not of the payload, and thus &MAY; be added or 1637 removed by any implementation along the request/response chain. 1610 1638 Additional information about the encoding parameters &MAY; be provided 1611 1639 by other header fields not defined by this specification. 1612 1640 </t> 1613 1641 <t> 1614 Many older HTTP/1.0 applications do not understand the Transfer-Encoding 1615 header field. 1616 </t> 1617 <t> 1618 If more than one 1619 Transfer-Encoding header field is present in a message, the multiple 1620 field-values &MUST; be combined into one field-value, according to the 1621 algorithm defined in <xref target="header.fields"/>, before determining 1622 the message-body length. 1623 </t> 1624 <t> 1625 When one or more transfer-codings are applied to a payload in order to 1626 form the message-body, the Transfer-Encoding header field &MUST; contain 1627 the list of transfer-codings applied. Transfer-Encoding is a property of 1628 the message, not of the payload, and thus &MAY; be added or removed by 1629 any implementation along the request/response chain under the constraints 1630 found in <xref target="transfer.codings"/>. 1642 Transfer-Encoding was added in HTTP/1.1. It is generally assumed that 1643 implementations advertising only HTTP/1.0 support will not understand 1644 how to process a transfer-encoded payload. 1645 A client &MUST-NOT; send a request containing Transfer-Encoding unless it 1646 knows the server will handle HTTP/1.1 (or later) requests; such knowledge 1647 might be in the form of specific user configuration or by remembering the 1648 version of a prior received response. 1649 A server &MUST-NOT; send a response containing Transfer-Encoding unless 1650 the corresponding request indicates HTTP/1.1 (or later). 1651 </t> 1652 <t> 1653 A server that receives a request message with a transfer-coding it does 1654 not understand &SHOULD; respond with 501 (Not Implemented) and then 1655 close the connection. 1631 1656 </t> 1632 1657 </section> … … 1688 1713 <section title="Message Body Length" anchor="message.body.length"> 1689 1714 <t> 1690 The length of themessage-body is determined by one of the following1715 The length of a message-body is determined by one of the following 1691 1716 (in order of precedence): 1692 1717 </t> … … 1701 1726 <x:lt><t> 1702 1727 If a Transfer-Encoding header field is present 1703 and the "chunked" transfer-coding (<xref target=" transfer.codings"/>)1728 and the "chunked" transfer-coding (<xref target="chunked.encoding"/>) 1704 1729 is the final encoding, the message-body length is determined by reading 1705 1730 and decoding the chunked data until the transfer-coding indicates the … … 2111 2136 </section> 2112 2137 2113 <section title="Associating Response to Request" anchor="associating.request.response">2138 <section title="Associating a Response to a Request" anchor="associating.response.to.request"> 2114 2139 <t> 2115 2140 HTTP does not include a request identifier for associating a given … … 2165 2190 transfer-coding values in the TE header field (<xref target="header.te"/>) and in 2166 2191 the Transfer-Encoding header field (<xref target="header.transfer-encoding"/>). 2167 </t>2168 <t>2169 Transfer-codings are analogous to the Content-Transfer-Encoding values of2170 MIME, which were designed to enable safe transport of binary data over a2171 7-bit transport service (<xref target="RFC2045" x:fmt="," x:sec="6"/>).2172 However, safe transport2173 has a different focus for an 8bit-clean transfer protocol. In HTTP,2174 the only unsafe characteristic of message-bodies is the difficulty in2175 determining the exact message body length (<xref target="message.body"/>),2176 or the desire to encrypt data over a shared transport.2177 </t>2178 <t>2179 A server that receives a request message with a transfer-coding it does2180 not understand &SHOULD; respond with 501 (Not Implemented) and then2181 close the connection. A server &MUST-NOT; send transfer-codings to an HTTP/1.02182 client.2183 2192 </t> 2184 2193 … … 2291 2300 Use of chunk-ext extensions by senders is deprecated; they &SHOULD-NOT; be 2292 2301 sent and definition of new chunk-extensions is discouraged. 2293 </t>2294 <t>2295 Since "chunked" is the only transfer-coding required to be understood2296 by HTTP/1.1 recipients, it plays a crucial role in delimiting messages2297 on a persistent connection. Whenever a transfer-coding is applied to2298 a payload body in a request, the final transfer-coding applied &MUST;2299 be "chunked". If a transfer-coding is applied to a response payload2300 body, then either the final transfer-coding applied &MUST; be "chunked"2301 or the message &MUST; be terminated by closing the connection. When the2302 "chunked" transfer-coding is used, it &MUST; be the last transfer-coding2303 applied to form the message-body. The "chunked" transfer-coding &MUST-NOT;2304 be applied more than once in a message-body.2305 2302 </t> 2306 2303 </section>
Note: See TracChangeset
for help on using the changeset viewer.