Changeset 1832
- Timestamp:
- 19/08/12 21:59:58 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1831 r1832 619 619 </li> 620 620 <li><a href="#rfc.section.4">4.</a> <a href="#transfer.codings">Transfer Codings</a><ul> 621 <li><a href="#rfc.section.4.1">4.1</a> <a href="#chunked.encoding">Chunked Transfer Coding</a></li> 621 <li><a href="#rfc.section.4.1">4.1</a> <a href="#chunked.encoding">Chunked Transfer Coding</a><ul> 622 <li><a href="#rfc.section.4.1.1">4.1.1</a> <a href="#header.trailer">Trailer</a></li> 623 <li><a href="#rfc.section.4.1.2">4.1.2</a> <a href="#decoding.chunked">Decoding chunked</a></li> 624 </ul> 625 </li> 622 626 <li><a href="#rfc.section.4.2">4.2</a> <a href="#compression.codings">Compression Codings</a><ul> 623 627 <li><a href="#rfc.section.4.2.1">4.2.1</a> <a href="#compress.coding">Compress Coding</a></li> … … 627 631 </li> 628 632 <li><a href="#rfc.section.4.3">4.3</a> <a href="#header.te">TE</a></li> 629 <li><a href="#rfc.section.4.4">4.4</a> <a href="#header.trailer">Trailer</a></li>630 633 </ul> 631 634 </li> … … 1577 1580 ; like <a href="#rule.quoted-string" class="smpl">quoted-string</a>, but disallowing line folding 1578 1581 <a href="#chunked.encoding" class="smpl">qdtext-nf</a> = <a href="#core.rules" class="smpl">HTAB</a> / <a href="#core.rules" class="smpl">SP</a> / %x21 / %x23-5B / %x5D-7E / <a href="#rule.quoted-string" class="smpl">obs-text</a> 1579 </pre><p id="rfc.section.4.1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked encoding is ended 1582 </pre><p id="rfc.section.4.1.p.3">Chunk extensions within the chucked encoding are deprecated. Senders <em class="bcp14">SHOULD NOT</em> send chunk-ext. Definition of new chunk extensions is discouraged. 1583 </p> 1584 <p id="rfc.section.4.1.p.4">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked encoding is ended 1580 1585 by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line. 1581 1586 </p> 1582 <p id="rfc.section.4.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The <a href="#header.trailer" class="smpl">Trailer</a> header field can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section 4.4</a>). 1583 </p> 1584 <p id="rfc.section.4.1.p.5">A server using chunked transfer-coding in a response <em class="bcp14">MUST NOT</em> use the trailer for any header fields unless at least one of the following is true: 1587 <div id="rfc.iref.t.5"></div> 1588 <div id="rfc.iref.h.8"></div> 1589 <h3 id="rfc.section.4.1.1"><a href="#rfc.section.4.1.1">4.1.1</a> <a id="header.trailer" href="#header.trailer">Trailer</a></h3> 1590 <p id="rfc.section.4.1.1.p.1">A trailer allows the sender to include additional fields at the end of a chunked message in order to supply metadata that 1591 might be dynamically generated while the message body is sent, such as a message integrity check, digital signature, or post-processing 1592 status. The trailer <em class="bcp14">MUST NOT</em> contain fields that need to be known before a recipient processes the body, such as <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, and <a href="#header.trailer" class="smpl">Trailer</a>. 1593 </p> 1594 <p id="rfc.section.4.1.1.p.2">When a message includes a message body encoded with the chunked transfer-coding and the sender desires to send metadata in 1595 the form of trailer fields at the end of the message, the sender <em class="bcp14">SHOULD</em> send a <a href="#header.trailer" class="smpl">Trailer</a> header field before the message body to indicate which fields will be present in the trailers. This allows the recipient to 1596 prepare for receipt of that metadata before it starts processing the body, which is useful if the message is being streamed 1597 and the recipient wishes to confirm an integrity check on the fly. 1598 </p> 1599 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.73"></span> <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a> 1600 </pre><p id="rfc.section.4.1.1.p.4">If no <a href="#header.trailer" class="smpl">Trailer</a> header field is present, the sender of a chunked message body <em class="bcp14">SHOULD</em> send an empty trailer. 1601 </p> 1602 <p id="rfc.section.4.1.1.p.5">A server <em class="bcp14">MUST</em> send an empty trailer with the chunked transfer-coding unless at least one of the following is true: 1585 1603 </p> 1586 1604 <ol> 1587 1605 <li>the request included a <a href="#header.te" class="smpl">TE</a> header field that indicates "trailers" is acceptable in the transfer-coding of the response, as described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section 4.3</a>; or, 1588 1606 </li> 1589 <li>the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable 1590 to the server where the field originated) without receiving it. In other words, the server that generated the header field 1591 (often but not always the origin server) is willing to accept the possibility that the trailer fields might be silently discarded 1592 along the path to the client. 1607 <li>the trailer fields consist entirely of optional metadata and the recipient could use the message (in a manner acceptable to 1608 the server where the field originated) without receiving that metadata. In other words, the server that generated the header 1609 field is willing to accept the possibility that the trailer fields might be silently discarded along the path to the client. 1593 1610 </li> 1594 1611 </ol> 1595 <p id="rfc.section.4.1. p.6">This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and1596 forwarded to an HTTP/1.0 recipient. It avoids a situation where conformance with the protocol would have necessitated a possibly1597 infinite buffer on the proxy.1598 < /p>1599 <p id="rfc.section.4.1. p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p>1600 <div id="rfc.figure.u.3 3"></div><pre class="text"> length := 01612 <p id="rfc.section.4.1.1.p.6">The above requirement prevents the need for an infinite buffer when a message is being received by an HTTP/1.1 (or later) 1613 proxy and forwarded to an HTTP/1.0 recipient. 1614 </p> 1615 <h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a> <a id="decoding.chunked" href="#decoding.chunked">Decoding chunked</a></h3> 1616 <p id="rfc.section.4.1.2.p.1">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p> 1617 <div id="rfc.figure.u.34"></div><pre class="text"> length := 0 1601 1618 read chunk-size, chunk-ext (if any) and CRLF 1602 1619 while (chunk-size > 0) { … … 1613 1630 Content-Length := length 1614 1631 Remove "chunked" from Transfer-Encoding 1615 </pre><p id="rfc.section.4.1.p.9">All HTTP/1.1 applications <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand. 1616 </p> 1617 <p id="rfc.section.4.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. 1632 Remove Trailer from existing header fields 1633 </pre><p id="rfc.section.4.1.2.p.3">All HTTP/1.1 applications <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand. 1618 1634 </p> 1619 1635 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="compression.codings" href="#compression.codings">Compression Codings</a></h2> … … 1634 1650 </p> 1635 1651 </div> 1636 <div id="rfc.iref.g.7 3"></div>1652 <div id="rfc.iref.g.74"></div> 1637 1653 <div id="rfc.iref.c.12"></div> 1638 1654 <h3 id="rfc.section.4.2.3"><a href="#rfc.section.4.2.3">4.2.3</a> <a id="gzip.coding" href="#gzip.coding">Gzip Coding</a></h3> 1639 1655 <p id="rfc.section.4.2.3.p.1">The "gzip" format is produced by the file compression program "gzip" (GNU zip), as described in <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC. Recipients <em class="bcp14">SHOULD</em> consider "x-gzip" to be equivalent to "gzip". 1640 1656 </p> 1641 <div id="rfc.iref.t. 5"></div>1642 <div id="rfc.iref.h. 8"></div>1657 <div id="rfc.iref.t.6"></div> 1658 <div id="rfc.iref.h.9"></div> 1643 1659 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="header.te" href="#header.te">TE</a></h2> 1644 1660 <p id="rfc.section.4.3.p.1">The "TE" header field in a request indicates what transfer-codings, besides "chunked", the client is willing to accept in … … 1648 1664 described in <a href="#transfer.codings" title="Transfer Codings">Section 4</a>), and/or the keyword "trailers". Clients <em class="bcp14">MUST NOT</em> send the chunked transfer-coding name in TE; chunked is always acceptable for HTTP/1.1 recipients. 1649 1665 </p> 1650 <div id="rfc.figure.u.3 4"></div><pre class="inline"><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span> <a href="#header.te" class="smpl">TE</a> = #<a href="#header.te" class="smpl">t-codings</a>1666 <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span> <a href="#header.te" class="smpl">TE</a> = #<a href="#header.te" class="smpl">t-codings</a> 1651 1667 <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-coding</a> [ <a href="#header.te" class="smpl">t-ranking</a> ] ) 1652 1668 <a href="#header.te" class="smpl">t-ranking</a> = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> "q=" <a href="#header.te" class="smpl">rank</a> … … 1654 1670 / ( "1" [ "." 0*3("0") ] ) 1655 1671 </pre><p id="rfc.section.4.3.p.4">Three examples of TE use are below.</p> 1656 <div id="rfc.figure.u.3 5"></div><pre class="text"> TE: deflate1672 <div id="rfc.figure.u.36"></div><pre class="text"> TE: deflate 1657 1673 TE: 1658 1674 TE: trailers, deflate;q=0.5 … … 1671 1687 <p id="rfc.section.4.3.p.9">Since the TE header field only applies to the immediate connection, a sender of TE <em class="bcp14">MUST</em> also send a "TE" connection option within the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section 6.1</a>) in order to prevent the TE field from being forwarded by intermediaries that do not support its semantics. 1672 1688 </p> 1673 <div id="rfc.iref.t.6"></div>1674 <div id="rfc.iref.h.9"></div>1675 <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="header.trailer" href="#header.trailer">Trailer</a></h2>1676 <p id="rfc.section.4.4.p.1">The "Trailer" header field indicates that the given set of header fields is present in the trailer of a message encoded with1677 chunked transfer-coding.1678 </p>1679 <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.78"></span> <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>1680 </pre><p id="rfc.section.4.4.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient1681 to know which header fields to expect in the trailer.1682 </p>1683 <p id="rfc.section.4.4.p.4">If no Trailer header field is present, the trailer <em class="bcp14">SHOULD NOT</em> include any header fields. See <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding.1684 </p>1685 <p id="rfc.section.4.4.p.5">Message header fields listed in the Trailer header field <em class="bcp14">MUST NOT</em> include the following header fields:1686 </p>1687 <ul>1688 <li><a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a></li>1689 <li><a href="#header.content-length" class="smpl">Content-Length</a></li>1690 <li><a href="#header.trailer" class="smpl">Trailer</a></li>1691 </ul>1692 1689 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="message.routing" href="#message.routing">Message Routing</a></h1> 1693 1690 <p id="rfc.section.5.p.1">HTTP request message routing is determined by each client based on the target resource, the client's proxy configuration, … … 2269 2266 <td class="left">http</td> 2270 2267 <td class="left">standard</td> 2271 <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer. 2" title="Trailer">Section 4.4</a>2268 <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section 4.1.1</a> 2272 2269 </td> 2273 2270 </tr> … … 3635 3632 <li><tt>quoted-str-nf</tt> <a href="#rfc.iref.g.71"><b>4.1</b></a></li> 3636 3633 <li><tt>quoted-string</tt> <a href="#rfc.iref.g.45"><b>3.2.4</b></a></li> 3637 <li><tt>rank</tt> <a href="#rfc.iref.g.7 7"><b>4.3</b></a></li>3634 <li><tt>rank</tt> <a href="#rfc.iref.g.78"><b>4.3</b></a></li> 3638 3635 <li><tt>reason-phrase</tt> <a href="#rfc.iref.g.32"><b>3.1.2</b></a></li> 3639 3636 <li><tt>received-by</tt> <a href="#rfc.iref.g.91"><b>6.2</b></a></li> … … 3647 3644 <li><tt>status-code</tt> <a href="#rfc.iref.g.31"><b>3.1.2</b></a></li> 3648 3645 <li><tt>status-line</tt> <a href="#rfc.iref.g.30"><b>3.1.2</b></a></li> 3649 <li><tt>t-codings</tt> <a href="#rfc.iref.g.7 5"><b>4.3</b></a></li>3650 <li><tt>t-ranking</tt> <a href="#rfc.iref.g.7 6"><b>4.3</b></a></li>3646 <li><tt>t-codings</tt> <a href="#rfc.iref.g.76"><b>4.3</b></a></li> 3647 <li><tt>t-ranking</tt> <a href="#rfc.iref.g.77"><b>4.3</b></a></li> 3651 3648 <li><tt>tchar</tt> <a href="#rfc.iref.g.43"><b>3.2.4</b></a></li> 3652 <li><tt>TE</tt> <a href="#rfc.iref.g.7 4"><b>4.3</b></a></li>3649 <li><tt>TE</tt> <a href="#rfc.iref.g.75"><b>4.3</b></a></li> 3653 3650 <li><tt>token</tt> <a href="#rfc.iref.g.42"><b>3.2.4</b></a></li> 3654 <li><tt>Trailer</tt> <a href="#rfc.iref.g.7 8"><b>4.4</b></a></li>3651 <li><tt>Trailer</tt> <a href="#rfc.iref.g.73"><b>4.1.1</b></a></li> 3655 3652 <li><tt>trailer-part</tt> <a href="#rfc.iref.g.70"><b>4.1</b></a></li> 3656 3653 <li><tt>transfer-coding</tt> <a href="#rfc.iref.g.55"><b>4</b></a></li> … … 3667 3664 </ul> 3668 3665 </li> 3669 <li>gzip (Coding Format) <a href="#rfc.iref.g.7 3">4.2.3</a></li>3666 <li>gzip (Coding Format) <a href="#rfc.iref.g.74">4.2.3</a></li> 3670 3667 </ul> 3671 3668 </li> … … 3677 3674 <li>Content-Length <a href="#rfc.iref.h.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a></li> 3678 3675 <li>Host <a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.iref.h.11"><b>5.4</b></a>, <a href="#rfc.xref.header.host.2">7.1</a>, <a href="#rfc.xref.header.host.3">A.1.1</a></li> 3679 <li>TE <a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1 </a>, <a href="#rfc.iref.h.8"><b>4.3</b></a>, <a href="#rfc.xref.header.te.3">7.1</a></li>3680 <li>Trailer <a href="#rfc. xref.header.trailer.1">4.1</a>, <a href="#rfc.iref.h.9"><b>4.4</b></a>, <a href="#rfc.xref.header.trailer.2">7.1</a></li>3676 <li>TE <a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1.1</a>, <a href="#rfc.iref.h.9"><b>4.3</b></a>, <a href="#rfc.xref.header.te.3">7.1</a></li> 3677 <li>Trailer <a href="#rfc.iref.h.8"><b>4.1.1</b></a>, <a href="#rfc.xref.header.trailer.1">7.1</a></li> 3681 3678 <li>Transfer-Encoding <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.h.6"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">4</a>, <a href="#rfc.xref.header.transfer-encoding.3">7.1</a>, <a href="#rfc.xref.header.transfer-encoding.4">A.1.3</a></li> 3682 3679 <li>Upgrade <a href="#rfc.iref.h.14"><b>6.5</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li> … … 3859 3856 <li>target resource <a href="#rfc.iref.t.7"><b>5.1</b></a></li> 3860 3857 <li>target URI <a href="#rfc.iref.t.8"><b>5.1</b></a></li> 3861 <li>TE header field <a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1 </a>, <a href="#rfc.iref.t.5"><b>4.3</b></a>, <a href="#rfc.xref.header.te.3">7.1</a></li>3858 <li>TE header field <a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1.1</a>, <a href="#rfc.iref.t.6"><b>4.3</b></a>, <a href="#rfc.xref.header.te.3">7.1</a></li> 3862 3859 <li><em>Tou1998</em> <a href="#rfc.xref.Tou1998.1">6.3.1</a>, <a href="#Tou1998"><b>10.2</b></a></li> 3863 <li>Trailer header field <a href="#rfc. xref.header.trailer.1">4.1</a>, <a href="#rfc.iref.t.6"><b>4.4</b></a>, <a href="#rfc.xref.header.trailer.2">7.1</a></li>3860 <li>Trailer header field <a href="#rfc.iref.t.5"><b>4.1.1</b></a>, <a href="#rfc.xref.header.trailer.1">7.1</a></li> 3864 3861 <li>Transfer-Encoding header field <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.t.4"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">4</a>, <a href="#rfc.xref.header.transfer-encoding.3">7.1</a>, <a href="#rfc.xref.header.transfer-encoding.4">A.1.3</a></li> 3865 3862 <li>transforming proxy <a href="#rfc.iref.t.1"><b>2.4</b></a></li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1831 r1832 1912 1912 </artwork></figure> 1913 1913 <t> 1914 Chunk extensions within the chucked encoding are deprecated. 1915 Senders &SHOULD-NOT; send chunk-ext. 1916 Definition of new chunk extensions is discouraged. 1917 </t> 1918 <t> 1914 1919 The chunk-size field is a string of hex digits indicating the size of 1915 1920 the chunk-data in octets. The chunked encoding is ended by any chunk whose size is 1916 1921 zero, followed by the trailer, which is terminated by an empty line. 1917 1922 </t> 1918 <t> 1919 The trailer allows the sender to include additional HTTP header 1920 fields at the end of the message. The <x:ref>Trailer</x:ref> header field 1921 can be used to indicate which header fields are included in a trailer (see 1922 <xref target="header.trailer"/>). 1923 </t> 1924 <t> 1925 A server using chunked transfer-coding in a response &MUST-NOT; use the 1926 trailer for any header fields unless at least one of the following is 1927 true: 1923 1924 <section title="Trailer" anchor="header.trailer"> 1925 <iref primary="true" item="Trailer header field" x:for-anchor=""/> 1926 <iref primary="true" item="Header Fields" subitem="Trailer" x:for-anchor=""/> 1927 <x:anchor-alias value="Trailer"/> 1928 <t> 1929 A trailer allows the sender to include additional fields at the end of a 1930 chunked message in order to supply metadata that might be dynamically 1931 generated while the message body is sent, such as a message integrity 1932 check, digital signature, or post-processing status. 1933 The trailer &MUST-NOT; contain fields that need to be known before a 1934 recipient processes the body, such as <x:ref>Transfer-Encoding</x:ref>, 1935 <x:ref>Content-Length</x:ref>, and <x:ref>Trailer</x:ref>. 1936 </t> 1937 <t> 1938 When a message includes a message body encoded with the chunked 1939 transfer-coding and the sender desires to send metadata in the form of 1940 trailer fields at the end of the message, the sender &SHOULD; send a 1941 <x:ref>Trailer</x:ref> header field before the message body to indicate 1942 which fields will be present in the trailers. This allows the recipient 1943 to prepare for receipt of that metadata before it starts processing the body, 1944 which is useful if the message is being streamed and the recipient wishes 1945 to confirm an integrity check on the fly. 1946 </t> 1947 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Trailer"/> 1948 <x:ref>Trailer</x:ref> = 1#<x:ref>field-name</x:ref> 1949 </artwork></figure> 1950 <t> 1951 If no <x:ref>Trailer</x:ref> header field is present, the sender of a 1952 chunked message body &SHOULD; send an empty trailer. 1953 </t> 1954 <t> 1955 A server &MUST; send an empty trailer with the chunked transfer-coding 1956 unless at least one of the following is true: 1928 1957 <list style="numbers"> 1929 1958 <t>the request included a <x:ref>TE</x:ref> header field that indicates … … 1931 1960 described in <xref target="header.te"/>; or,</t> 1932 1961 1933 <t>the trailer fields consist entirely of optional metadata ,and the1962 <t>the trailer fields consist entirely of optional metadata and the 1934 1963 recipient could use the message (in a manner acceptable to the server where 1935 the field originated) without receiving it. In other words, the server that1936 generated the header field (often but not always the origin server) is1937 willing to accept the possibility that the trailer fields might be silently1938 discarded alongthe path to the client.</t>1964 the field originated) without receiving that metadata. In other words, 1965 the server that generated the header field is willing to accept the 1966 possibility that the trailer fields might be silently discarded along 1967 the path to the client.</t> 1939 1968 </list> 1940 1969 </t> 1941 1970 <t> 1942 This requirement prevents an interoperability failure when the 1943 message is being received by an HTTP/1.1 (or later) proxy and 1944 forwarded to an HTTP/1.0 recipient. It avoids a situation where 1945 conformance with the protocol would have necessitated a possibly 1946 infinite buffer on the proxy. 1947 </t> 1971 The above requirement prevents the need for an infinite buffer when a 1972 message is being received by an HTTP/1.1 (or later) proxy and forwarded to 1973 an HTTP/1.0 recipient. 1974 </t> 1975 </section> 1976 1977 <section title="Decoding chunked" anchor="decoding.chunked"> 1948 1978 <t> 1949 1979 A process for decoding the "chunked" transfer-coding … … 1966 1996 Content-Length := length 1967 1997 Remove "chunked" from Transfer-Encoding 1998 Remove Trailer from existing header fields 1968 1999 </artwork></figure> 1969 2000 <t> … … 1972 2003 they do not understand. 1973 2004 </t> 1974 <t> 1975 Use of chunk-ext extensions by senders is deprecated; they &SHOULD-NOT; be 1976 sent and definition of new chunk-extensions is discouraged. 1977 </t> 2005 </section> 1978 2006 </section> 1979 2007 … … 2090 2118 in order to prevent the TE field from being forwarded by intermediaries 2091 2119 that do not support its semantics. 2092 </t>2093 </section>2094 2095 <section title="Trailer" anchor="header.trailer">2096 <iref primary="true" item="Trailer header field" x:for-anchor=""/>2097 <iref primary="true" item="Header Fields" subitem="Trailer" x:for-anchor=""/>2098 <x:anchor-alias value="Trailer"/>2099 <t>2100 The "Trailer" header field indicates that the given set of2101 header fields is present in the trailer of a message encoded with2102 chunked transfer-coding.2103 </t>2104 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Trailer"/>2105 <x:ref>Trailer</x:ref> = 1#<x:ref>field-name</x:ref>2106 </artwork></figure>2107 <t>2108 An HTTP/1.1 message &SHOULD; include a Trailer header field in a2109 message using chunked transfer-coding with a non-empty trailer. Doing2110 so allows the recipient to know which header fields to expect in the2111 trailer.2112 </t>2113 <t>2114 If no Trailer header field is present, the trailer &SHOULD-NOT; include2115 any header fields. See <xref target="chunked.encoding"/> for restrictions on the use of2116 trailer fields in a "chunked" transfer-coding.2117 </t>2118 <t>2119 Message header fields listed in the Trailer header field &MUST-NOT;2120 include the following header fields:2121 <list style="symbols">2122 <t><x:ref>Transfer-Encoding</x:ref></t>2123 <t><x:ref>Content-Length</x:ref></t>2124 <t><x:ref>Trailer</x:ref></t>2125 </list>2126 2120 </t> 2127 2121 </section>
Note: See TracChangeset
for help on using the changeset viewer.