![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 1832 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- Aug 19, 2012, 2:59:58 PM (7 years ago)
- File:
-
- 1 edited
-
draft-ietf-httpbis/latest/p1-messaging.html (modified) (14 diffs)
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>
Note: See TracChangeset
for help on using the changeset viewer.
