Changeset 2031 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 05/12/12 16:59:49 (8 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r2030 r2031 1478 1478 <section title="Transfer-Encoding" anchor="header.transfer-encoding"> 1479 1479 <iref primary="true" item="Transfer-Encoding header field" x:for-anchor=""/> 1480 <iref item="chunked (Coding Format)"/> 1480 1481 <x:anchor-alias value="Transfer-Encoding"/> 1481 1482 <t> 1482 When one or more transfer codings are applied to a payload body in order 1483 to form the message body, a Transfer-Encoding header field &MUST; be sent 1484 in the message and &MUST; contain the list of corresponding 1485 transfer-coding names in the same order that they were applied. 1483 The Transfer-Encoding header field lists the transfer coding names 1484 corresponding to the sequence of transfer codings that have been 1485 (or will be) applied to the payload body in order to form the message body. 1486 1486 Transfer codings are defined in <xref target="transfer.codings"/>. 1487 1487 </t> … … 1497 1497 accurately delimit a dynamically generated payload and to distinguish 1498 1498 payload encodings that are only applied for transport efficiency or 1499 security from those that are characteristics of the targetresource.1500 </t> 1501 <t> 1502 The "chunked" transfer-coding (<xref target="chunked.encoding"/>)1503 &MUST; be implemented by all HTTP/1.1 recipients because it plays a1504 crucial role in delimiting messages when the payload body size is not1505 known in advance.1506 When the "chunked" transfer-coding is used, it &MUST; be the last1507 transfer-coding applied to form the message body and &MUST-NOT;1508 be applied more than once in a message body.1509 If any transfer-coding is applied to a request payload body,1510 the final transfer-coding applied &MUST; be "chunked".1511 If any transfer -coding is applied to a response payload body, then either1512 the final transfer-coding applied &MUST; be "chunked"or1513 t he message &MUST; be terminatedby closing the connection.1499 security from those that are characteristics of the selected resource. 1500 </t> 1501 <t> 1502 All HTTP/1.1 recipients &MUST; implement the chunked transfer coding 1503 (<xref target="chunked.encoding"/>) because it plays a crucial role in 1504 framing messages when the payload body size is not known in advance. 1505 If chunked is applied to a payload body, the sender &MUST-NOT; apply 1506 chunked more than once (i.e., chunking an already chunked message is not 1507 allowed). 1508 If any transfer coding is applied to a request payload body, the 1509 sender &MUST; apply chunked as the final transfer coding to ensure that 1510 the message is properly framed. 1511 If any transfer coding is applied to a response payload body, the 1512 sender &MUST; either apply chunked as the final transfer coding or 1513 terminate the message by closing the connection. 1514 1514 </t> 1515 1515 <figure><preamble> … … 1523 1523 </postamble></figure> 1524 1524 <t> 1525 If more than one Transfer-Encoding header field is present in a message,1526 the multiple field-values &MUST; be combined into one field-value,1527 according to the algorithm defined in <xref target="header.fields"/>,1528 before determining the message body length.1529 </t>1530 <t>1531 1525 Unlike <x:ref>Content-Encoding</x:ref> (&content-codings;), 1532 Transfer-Encoding is a property of the message, not of the payload, and thus 1533 &MAY; be added or removed by any implementation along the request/response 1534 chain. Additional information about the encoding parameters &MAY; be 1526 Transfer-Encoding is a property of the message, not of the payload, and 1527 any recipient along the request/response chain &MAY; decode the received 1528 transfer coding(s) or apply additional transfer coding(s) to the message 1529 body, assuming that corresponding changes are made to the Transfer-Encoding 1530 field-value. Additional information about the encoding parameters &MAY; be 1535 1531 provided by other header fields not defined by this specification. 1536 1532 </t> … … 1557 1553 </t> 1558 1554 <t> 1559 A server that receives a request message with a transfer-coding it does 1560 not understand &SHOULD; respond with <x:ref>501 (Not Implemented)</x:ref> and then 1561 close the connection. 1555 A server that receives a request message with a transfer coding it does 1556 not understand &SHOULD; respond with <x:ref>501 (Not Implemented)</x:ref>. 1562 1557 </t> 1563 1558 </section> … … 1636 1631 1637 1632 <section title="Message Body Length" anchor="message.body.length"> 1633 <iref item="chunked (Coding Format)"/> 1638 1634 <t> 1639 1635 The length of a message body is determined by one of the following … … 1659 1655 <x:lt><t> 1660 1656 If a <x:ref>Transfer-Encoding</x:ref> header field is present 1661 and the "chunked" transfer-coding (<xref target="chunked.encoding"/>)1657 and the chunked transfer coding (<xref target="chunked.encoding"/>) 1662 1658 is the final encoding, the message body length is determined by reading 1663 and decoding the chunked data until the transfer -coding indicates the1659 and decoding the chunked data until the transfer coding indicates the 1664 1660 data is complete. 1665 1661 </t> 1666 1662 <t> 1667 1663 If a <x:ref>Transfer-Encoding</x:ref> header field is present in a 1668 response and the "chunked" transfer-coding is not the final encoding, the1664 response and the chunked transfer coding is not the final encoding, the 1669 1665 message body length is determined by reading the connection until it is 1670 1666 closed by the server. 1671 If a Transfer-Encodingheader field is present in a request and the1672 "chunked" transfer-coding is not the final encoding, the message body1667 If a <x:ref>Transfer-Encoding</x:ref> header field is present in a request and the 1668 chunked transfer coding is not the final encoding, the message body 1673 1669 length cannot be determined reliably; the server &MUST; respond with 1674 1670 the <x:ref>400 (Bad Request)</x:ref> status code and then close the connection. … … 1676 1672 <t> 1677 1673 If a message is received with both a <x:ref>Transfer-Encoding</x:ref> 1678 and a <x:ref>Content-Length</x:ref> header field, the 1679 Transfer-Encoding overrides the Content-Length. 1680 Such a message might indicate an attempt to perform request or response 1681 smuggling (bypass of security-related checks on message routing or content) 1682 and thus ought to be handled as an error. The provided Content-Length &MUST; 1683 be removed, prior to forwarding the message downstream, or replaced with 1684 the real message body length after the transfer-coding is decoded. 1674 and a <x:ref>Content-Length</x:ref> header field, the Transfer-Encoding 1675 overrides the Content-Length. Such a message might indicate an attempt 1676 to perform request or response smuggling (bypass of security-related 1677 checks on message routing or content) and thus ought to be handled as 1678 an error. A sender &MUST; remove the received Content-Length field 1679 prior to forwarding such a message downstream. 1685 1680 </t></x:lt> 1686 1681 <x:lt><t> … … 1737 1732 </t> 1738 1733 <t> 1739 Unless a transfer -coding other than "chunked"has been applied,1734 Unless a transfer coding other than chunked has been applied, 1740 1735 a client that sends a request containing a message body &SHOULD; 1741 1736 use a valid <x:ref>Content-Length</x:ref> header field if the message body 1742 length is known in advance, rather than the "chunked" encoding, since some1743 existing services respond to "chunked"with a <x:ref>411 (Length Required)</x:ref>1744 status code even though they understand the chunked encoding. This1737 length is known in advance, rather than the chunked transfer coding, since some 1738 existing services respond to chunked with a <x:ref>411 (Length Required)</x:ref> 1739 status code even though they understand the chunked transfer coding. This 1745 1740 is typically because such services are implemented via a gateway that 1746 1741 requires a content-length in advance of being called and the server … … 1759 1754 <section anchor="incomplete.messages" title="Handling Incomplete Messages"> 1760 1755 <t> 1761 Request messages that are prematurely terminated, possibly due to a 1762 canceled connection or a server-imposed time-out exception, &MUST; 1763 result in closure of the connection; sending an error response 1764 prior to closing the connection is &OPTIONAL;. 1765 </t> 1766 <t> 1767 Response messages that are prematurely terminated, usually by closure 1768 of the connection prior to receiving the expected number of octets or by 1769 failure to decode a transfer-encoded message body, &MUST; be recorded 1770 as incomplete. A response that terminates in the middle of the header 1771 block (before the empty line is received) cannot be assumed to convey the 1772 full semantics of the response and &MUST; be treated as an error. 1773 </t> 1774 <t> 1775 A message body that uses the chunked transfer encoding is 1756 A server that receives an incomplete request message, usually due to a 1757 canceled request or a triggered time-out exception, &MAY; send an error 1758 response prior to closing the connection. 1759 </t> 1760 <t> 1761 A client that receives an incomplete response message, which can occur 1762 when a connection is closed prematurely or when decoding a supposedly 1763 chunked transfer coding fails, &MUST; record the message as incomplete. 1764 If a response terminates in the middle of the header block (before the 1765 empty line is received) and the status code might rely on header fields to 1766 convey the full meaning of the response, then the client cannot assume 1767 that meaning has been conveyed; the client might need to repeat the 1768 request in order to determine what action to take next. 1769 </t> 1770 <t> 1771 A message body that uses the chunked transfer coding is 1776 1772 incomplete if the zero-sized chunk that terminates the encoding has not 1777 1773 been received. A message that uses a valid <x:ref>Content-Length</x:ref> is 1778 1774 incomplete if the size of the message body received (in octets) is less than 1779 1775 the value given by Content-Length. A response that has neither chunked 1780 transfer encoding nor Content-Length is terminated by closure of the1776 transfer coding nor Content-Length is terminated by closure of the 1781 1777 connection, and thus is considered complete regardless of the number of 1782 1778 message body octets received, provided that the header block was received … … 1802 1798 <section title="Message Parsing Robustness" anchor="message.robustness"> 1803 1799 <t> 1804 Older HTTP/1.0 client implementations might send an extra CRLF1800 Older HTTP/1.0 user agent implementations might send an extra CRLF 1805 1801 after a POST request as a lame workaround for some early server 1806 1802 applications that failed to read message body content that was 1807 not terminated by a line-ending. An HTTP/1.1 client &MUST-NOT;1803 not terminated by a line-ending. An HTTP/1.1 user agent &MUST-NOT; 1808 1804 preface or follow a request with an extra CRLF. If terminating 1809 1805 the request message body with a line-ending is desired, then the 1810 client &MUST; include the terminating CRLF octets as part of the1806 user agent &MUST; include the terminating CRLF octets as part of the 1811 1807 message body length. 1812 1808 </t> … … 1814 1810 In the interest of robustness, servers &SHOULD; ignore at least one 1815 1811 empty line received where a request-line is expected. In other words, if 1816 theserver is reading the protocol stream at the beginning of a1817 message and receives a CRLF first, it&SHOULD; ignore the CRLF.1812 a server is reading the protocol stream at the beginning of a 1813 message and receives a CRLF first, the server &SHOULD; ignore the CRLF. 1818 1814 </t> 1819 1815 <t> … … 1845 1841 <x:anchor-alias value="transfer-extension"/> 1846 1842 <t> 1847 Transfer -coding values are used to indicate an encoding1843 Transfer coding names are used to indicate an encoding 1848 1844 transformation that has been, can be, or might need to be applied to a 1849 1845 payload body in order to ensure "safe transport" through the network. 1850 This differs from a content coding in that the transfer -coding is a1846 This differs from a content coding in that the transfer coding is a 1851 1847 property of the message rather than a property of the representation 1852 1848 that is being transferred. … … 1872 1868 </artwork></figure> 1873 1869 <t> 1874 All transfer-coding values are case-insensitive and &SHOULD; be registered1870 All transfer-coding names are case-insensitive and &SHOULD; be registered 1875 1871 within the HTTP Transfer Coding registry, as defined in 1876 1872 <xref target="transfer.coding.registry"/>. … … 1881 1877 1882 1878 <section title="Chunked Transfer Coding" anchor="chunked.encoding"> 1883 <iref item="chunked (Coding Format)"/>1879 <iref primary="true" item="chunked (Coding Format)"/> 1884 1880 <x:anchor-alias value="chunk"/> 1885 1881 <x:anchor-alias value="chunked-body"/> … … 1894 1890 <x:anchor-alias value="qdtext-nf"/> 1895 1891 <t> 1896 The chunked encoding modifies the body of a message in order to1892 The chunked transfer coding modifies the body of a message in order to 1897 1893 transfer it as a series of chunks, each with its own size indicator, 1898 1894 followed by an &OPTIONAL; trailer containing header fields. This … … 1923 1919 </artwork></figure> 1924 1920 <t> 1925 Chunk extensions within the chu cked encoding are deprecated.1921 Chunk extensions within the chunked transfer coding are deprecated. 1926 1922 Senders &SHOULD-NOT; send chunk-ext. 1927 1923 Definition of new chunk extensions is discouraged. … … 1929 1925 <t> 1930 1926 The chunk-size field is a string of hex digits indicating the size of 1931 the chunk-data in octets. The chunked encoding is ended by any chunk whose size is 1932 zero, followed by the trailer, which is terminated by an empty line. 1927 the chunk-data in octets. The chunked transfer coding is complete when a 1928 chunk with a chunk-size of zero is received, possibly followed by a 1929 trailer, and finally terminated by an empty line. 1933 1930 </t> 1934 1931 … … 1947 1944 <t> 1948 1945 When a message includes a message body encoded with the chunked 1949 transfer -coding and the sender desires to send metadata in the form of1946 transfer coding and the sender desires to send metadata in the form of 1950 1947 trailer fields at the end of the message, the sender &SHOULD; send a 1951 1948 <x:ref>Trailer</x:ref> header field before the message body to indicate … … 1963 1960 </t> 1964 1961 <t> 1965 A server &MUST; send an empty trailer with the chunked transfer -coding1962 A server &MUST; send an empty trailer with the chunked transfer coding 1966 1963 unless at least one of the following is true: 1967 1964 <list style="numbers"> 1968 1965 <t>the request included a <x:ref>TE</x:ref> header field that indicates 1969 "trailers" is acceptable in the transfer -coding of the response, as1966 "trailers" is acceptable in the transfer coding of the response, as 1970 1967 described in <xref target="header.te"/>; or,</t> 1971 1968 … … 1987 1984 <section title="Decoding chunked" anchor="decoding.chunked"> 1988 1985 <t> 1989 A process for decoding the "chunked" transfer-coding1986 A process for decoding the chunked transfer coding 1990 1987 can be represented in pseudo-code as: 1991 1988 </t> … … 2010 2007 <t> 2011 2008 All recipients &MUST; be able to receive and decode the 2012 "chunked" transfer-coding and &MUST; ignore chunk-ext extensions2009 chunked transfer coding and &MUST; ignore chunk-ext extensions 2013 2010 they do not understand. 2014 2011 </t> … … 2066 2063 <x:anchor-alias value="rank"/> 2067 2064 <t> 2068 The "TE" header field in a request indicates what transfer -codings,2069 besides "chunked", the client is willing to accept in response, and2065 The "TE" header field in a request indicates what transfer codings, 2066 besides chunked, the client is willing to accept in response, and 2070 2067 whether or not the client is willing to accept trailer fields in a 2071 chunked transfer -coding.2072 </t> 2073 <t> 2074 The TE field-value consists of a comma-separated list of transfer -coding2068 chunked transfer coding. 2069 </t> 2070 <t> 2071 The TE field-value consists of a comma-separated list of transfer coding 2075 2072 names, each allowing for optional parameters (as described in 2076 2073 <xref target="transfer.codings"/>), and/or the keyword "trailers". 2077 Clients &MUST-NOT; send the chunked transfer -coding name in TE;2074 Clients &MUST-NOT; send the chunked transfer coding name in TE; 2078 2075 chunked is always acceptable for HTTP/1.1 recipients. 2079 2076 </t> … … 2095 2092 <t> 2096 2093 The presence of the keyword "trailers" indicates that the client is 2097 willing to accept trailer fields in a chunked transfer -coding,2094 willing to accept trailer fields in a chunked transfer coding, 2098 2095 as defined in <xref target="chunked.encoding"/>, on behalf of itself and 2099 2096 any downstream clients. For chained requests, this implies that either: … … 2107 2104 </t> 2108 2105 <t> 2109 When multiple transfer -codings are acceptable, the client &MAY; rank the2106 When multiple transfer codings are acceptable, the client &MAY; rank the 2110 2107 codings by preference using a case-insensitive "q" parameter (similar to 2111 2108 the qvalues used in content negotiation fields, &qvalue;). The rank value … … 2115 2112 <t> 2116 2113 If the TE field-value is empty or if no TE field is present, the only 2117 acceptable transfer -coding is "chunked". A message with no transfer-coding2114 acceptable transfer coding is chunked. A message with no transfer coding 2118 2115 is always acceptable. 2119 2116 </t> … … 2463 2460 </section> 2464 2461 2462 <section title="Associating a Response to a Request" anchor="associating.response.to.request"> 2463 <t> 2464 HTTP does not include a request identifier for associating a given 2465 request message with its corresponding one or more response messages. 2466 Hence, it relies on the order of response arrival to correspond exactly 2467 to the order in which requests are made on the same connection. 2468 More than one response message per request only occurs when one or more 2469 informational responses (<x:ref>1xx</x:ref>, see &status-1xx;) precede a 2470 final response to the same request. 2471 </t> 2472 <t> 2473 A client that has more than one outstanding request on a connection &MUST; 2474 maintain a list of outstanding requests in the order sent and &MUST; 2475 associate each received response message on that connection to the highest 2476 ordered request that has not yet received a final (non-<x:ref>1xx</x:ref>) 2477 response. 2478 </t> 2479 </section> 2480 2465 2481 <section title="Message Forwarding" anchor="message.forwarding"> 2466 2482 <t> … … 2484 2500 names, including any aliases, local variations, or literal IP addresses. 2485 2501 </t> 2486 </section>2487 2502 2488 2503 <section title="Via" anchor="header.via"> … … 2579 2594 </section> 2580 2595 2581 <section title=" Message Transforming" anchor="message.transforming">2596 <section title="Transformation" anchor="message.transformation"> 2582 2597 <t> 2583 2598 If a proxy receives a request-target with a host name that is not a … … 2594 2609 A non-transforming proxy &MUST; preserve the message payload (&payload;), 2595 2610 though it &MAY; change the message body through application or removal 2596 of a transfer -coding (<xref target="transfer.codings"/>).2611 of a transfer coding (<xref target="transfer.codings"/>). 2597 2612 </t> 2598 2613 <t> … … 2645 2660 </x:note> 2646 2661 </section> 2647 2648 <section title="Associating a Response to a Request" anchor="associating.response.to.request">2649 <t>2650 HTTP does not include a request identifier for associating a given2651 request message with its corresponding one or more response messages.2652 Hence, it relies on the order of response arrival to correspond exactly2653 to the order in which requests are made on the same connection.2654 More than one response message per request only occurs when one or more2655 informational responses (<x:ref>1xx</x:ref>, see &status-1xx;) precede a final response2656 to the same request.2657 </t>2658 <t>2659 A client that uses persistent connections and sends more than one request2660 per connection &MUST; maintain a list of outstanding requests in the2661 order sent on that connection and &MUST; associate each received response2662 message to the highest ordered request that has not yet received a final2663 (non-<x:ref>1xx</x:ref>) response.2664 </t>2665 2662 </section> 2666 2663 </section> … … 4736 4733 HTTP/1.1 introduces the <x:ref>Transfer-Encoding</x:ref> header field 4737 4734 (<xref target="header.transfer-encoding"/>). Proxies/gateways &MUST; remove 4738 any transfer -coding prior to forwarding a message via a MIME-compliant4735 any transfer coding prior to forwarding a message via a MIME-compliant 4739 4736 protocol. 4740 4737 </t> … … 4827 4824 </t> 4828 4825 <t> 4829 The "identity" transfer -coding valuetoken has been removed.4826 The "identity" transfer coding token has been removed. 4830 4827 (Sections <xref format="counter" target="message.body"/> and 4831 4828 <xref format="counter" target="transfer.codings"/>)
Note: See TracChangeset
for help on using the changeset viewer.