Changeset 2406
- Timestamp:
- 17/09/13 06:50:58 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2405 r2406 446 446 } 447 447 @bottom-center { 448 content: "Expires March 2 1, 2014";448 content: "Expires March 20, 2014"; 449 449 } 450 450 @bottom-right { … … 488 488 <meta name="dct.creator" content="Reschke, J. F."> 489 489 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 490 <meta name="dct.issued" scheme="ISO8601" content="2013-09-1 7">490 <meta name="dct.issued" scheme="ISO8601" content="2013-09-16"> 491 491 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 492 492 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 517 517 <tr> 518 518 <td class="left">Intended status: Standards Track</td> 519 <td class="right">September 1 7, 2013</td>519 <td class="right">September 16, 2013</td> 520 520 </tr> 521 521 <tr> 522 <td class="left">Expires: March 2 1, 2014</td>522 <td class="left">Expires: March 20, 2014</td> 523 523 <td class="right"></td> 524 524 </tr> … … 548 548 in progress”. 549 549 </p> 550 <p>This Internet-Draft will expire on March 2 1, 2014.</p>550 <p>This Internet-Draft will expire on March 20, 2014.</p> 551 551 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 552 552 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 613 613 <li><a href="#rfc.section.4">4.</a> <a href="#transfer.codings">Transfer Codings</a><ul> 614 614 <li><a href="#rfc.section.4.1">4.1</a> <a href="#chunked.encoding">Chunked Transfer Coding</a><ul> 615 <li><a href="#rfc.section.4.1.1">4.1.1</a> <a href="#chunked.trailer.part">Chunked Trailer Part</a></li> 616 <li><a href="#rfc.section.4.1.2">4.1.2</a> <a href="#decoding.chunked">Decoding Chunked</a></li> 615 <li><a href="#rfc.section.4.1.1">4.1.1</a> <a href="#chunked.extension">Chunk Extensions</a></li> 616 <li><a href="#rfc.section.4.1.2">4.1.2</a> <a href="#chunked.trailer.part">Chunked Trailer Part</a></li> 617 <li><a href="#rfc.section.4.1.3">4.1.3</a> <a href="#decoding.chunked">Decoding Chunked</a></li> 617 618 </ul> 618 619 </li> … … 1591 1592 <div id="rfc.iref.c.9"></div> 1592 1593 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="chunked.encoding" href="#chunked.encoding">Chunked Transfer Coding</a></h2> 1593 <p id="rfc.section.4.1.p.1">The chunked transfer coding modifies the body of a message in order to transfer it as a series of chunks, each with its own 1594 size indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing header fields. This allows dynamically generated content to be transferred along with the information necessary 1595 for the recipient to verify that it has received the full message. 1594 <p id="rfc.section.4.1.p.1">The chunked transfer coding wraps the payload body in order to transfer it as a series of chunks, each with its own size indicator, 1595 followed by an <em class="bcp14">OPTIONAL</em> trailer containing header fields. Chunked enables content streams of unknown size to be transferred as a sequence of length-delimited 1596 buffers, which enables the sender to retain connection persistence and the recipient to know when it has received the entire 1597 message. 1596 1598 </p> 1597 1599 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span> <a href="#chunked.encoding" class="smpl">chunked-body</a> = *<a href="#chunked.encoding" class="smpl">chunk</a> … … 1600 1602 <a href="#core.rules" class="smpl">CRLF</a> 1601 1603 1602 <a href="#chunked.encoding" class="smpl">chunk</a> = <a href="#chunked.encoding" class="smpl">chunk-size</a> [ <a href="#chunked.e ncoding" class="smpl">chunk-ext</a> ] <a href="#core.rules" class="smpl">CRLF</a>1604 <a href="#chunked.encoding" class="smpl">chunk</a> = <a href="#chunked.encoding" class="smpl">chunk-size</a> [ <a href="#chunked.extension" class="smpl">chunk-ext</a> ] <a href="#core.rules" class="smpl">CRLF</a> 1603 1605 <a href="#chunked.encoding" class="smpl">chunk-data</a> <a href="#core.rules" class="smpl">CRLF</a> 1604 1606 <a href="#chunked.encoding" class="smpl">chunk-size</a> = 1*<a href="#core.rules" class="smpl">HEXDIG</a> 1605 <a href="#chunked.encoding" class="smpl">last-chunk</a> = 1*("0") [ <a href="#chunked.e ncoding" class="smpl">chunk-ext</a> ] <a href="#core.rules" class="smpl">CRLF</a>1607 <a href="#chunked.encoding" class="smpl">last-chunk</a> = 1*("0") [ <a href="#chunked.extension" class="smpl">chunk-ext</a> ] <a href="#core.rules" class="smpl">CRLF</a> 1606 1608 1607 <a href="#chunked.encoding" class="smpl">chunk-ext</a> = *( ";" <a href="#chunked.encoding" class="smpl">chunk-ext-name</a> [ "=" <a href="#chunked.encoding" class="smpl">chunk-ext-val</a> ] )1608 <a href="#chunked.encoding" class="smpl">chunk-ext-name</a> = <a href="#rule.token.separators" class="smpl">token</a>1609 <a href="#chunked.encoding" class="smpl">chunk-ext-val</a> = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#chunked.encoding" class="smpl">quoted-str-nf</a>1610 1609 <a href="#chunked.encoding" class="smpl">chunk-data</a> = 1*<a href="#core.rules" class="smpl">OCTET</a> ; a sequence of chunk-size octets 1611 1612 <a href="#chunked.encoding" class="smpl">quoted-str-nf</a> = <a href="#core.rules" class="smpl">DQUOTE</a> *( <a href="#chunked.encoding" class="smpl">qdtext-nf</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> ) <a href="#core.rules" class="smpl">DQUOTE</a> 1613 ; like <a href="#rule.quoted-string" class="smpl">quoted-string</a>, but disallowing line folding 1614 <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> 1615 </pre><p id="rfc.section.4.1.p.3">Chunk extensions need to be used carefully because use of chunking does not have any semantics related to the message; it 1616 is by definition hop-by-hop and thus can be removed/reformatted by any intermediary. Furthermore, few implementations expose 1617 information about their contents. 1618 </p> 1619 <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 transfer coding 1610 </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 transfer coding 1620 1611 is complete when a chunk with a chunk-size of zero is received, possibly followed by a trailer, and finally terminated by 1621 1612 an empty line. 1622 1613 </p> 1623 <h3 id="rfc.section.4.1.1"><a href="#rfc.section.4.1.1">4.1.1</a> <a id="chunked.trailer.part" href="#chunked.trailer.part">Chunked Trailer Part</a></h3> 1624 <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 1614 <p id="rfc.section.4.1.p.4">A recipient <em class="bcp14">MUST</em> be able to parse and decode the chunked transfer coding. 1615 </p> 1616 <h3 id="rfc.section.4.1.1"><a href="#rfc.section.4.1.1">4.1.1</a> <a id="chunked.extension" href="#chunked.extension">Chunk Extensions</a></h3> 1617 <p id="rfc.section.4.1.1.p.1">The chunked encoding allows each chunk to include zero or more chunk extensions, immediately following the <a href="#chunked.encoding" class="smpl">chunk-size</a>, for the sake of supplying per-chunk metadata (such as a signature or hash), mid-message control information, or randomization 1618 of message body size. 1619 </p> 1620 <div id="rfc.figure.u.33"></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><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span> <a href="#chunked.extension" class="smpl">chunk-ext</a> = *( ";" <a href="#chunked.extension" class="smpl">chunk-ext-name</a> [ "=" <a href="#chunked.extension" class="smpl">chunk-ext-val</a> ] ) 1621 1622 <a href="#chunked.extension" class="smpl">chunk-ext-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 1623 <a href="#chunked.extension" class="smpl">chunk-ext-val</a> = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#chunked.extension" class="smpl">quoted-str-nf</a> 1624 1625 <a href="#chunked.extension" class="smpl">quoted-str-nf</a> = <a href="#core.rules" class="smpl">DQUOTE</a> *( <a href="#chunked.extension" class="smpl">qdtext-nf</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> ) <a href="#core.rules" class="smpl">DQUOTE</a> 1626 ; like <a href="#rule.quoted-string" class="smpl">quoted-string</a>, but disallowing line folding 1627 <a href="#chunked.extension" 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> 1628 </pre><p id="rfc.section.4.1.1.p.3">The chunked encoding is specific to each connection and is likely to be removed or recoded by each recipient (including intermediaries) 1629 before any higher-level application would have a chance to inspect the extensions. Hence, use of chunk extensions is generally 1630 limited to specialized HTTP services such as "long polling" (where client and server can have shared expectations regarding 1631 the use of chunk extensions) or for padding within an end-to-end secured connection. 1632 </p> 1633 <p id="rfc.section.4.1.1.p.4">A recipient <em class="bcp14">MUST</em> ignore unrecognized chunk extensions. A server ought to limit the total length of chunk extensions received in a request to 1634 an amount reasonable for the services provided, in the same way that it applies length limitations and timeouts for other 1635 parts of a message, and generate an appropriate <a href="p2-semantics.html#status.4xx" class="smpl">4xx (Client Error)</a> response if that amount is exceeded. 1636 </p> 1637 <h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a> <a id="chunked.trailer.part" href="#chunked.trailer.part">Chunked Trailer Part</a></h3> 1638 <p id="rfc.section.4.1.2.p.1">A trailer allows the sender to include additional fields at the end of a chunked message in order to supply metadata that 1625 1639 might be dynamically generated while the message body is sent, such as a message integrity check, digital signature, or post-processing 1626 1640 status. The trailer fields are identical to header fields, except they are sent in a chunked trailer instead of the message's 1627 1641 header section. 1628 1642 </p> 1629 <div id="rfc.figure.u.3 3"></div><pre class="inline"><span id="rfc.iref.g.75"></span> <a href="#chunked.trailer.part" class="smpl">trailer-part</a> = *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )1630 </pre><p id="rfc.section.4.1. 1.p.3">A sender <em class="bcp14">MUST NOT</em> generate a trailer that contains a field which needs to be known by the recipient before it can begin processing the message1643 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.86"></span> <a href="#chunked.trailer.part" class="smpl">trailer-part</a> = *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> ) 1644 </pre><p id="rfc.section.4.1.2.p.3">A sender <em class="bcp14">MUST NOT</em> generate a trailer that contains a field which needs to be known by the recipient before it can begin processing the message 1631 1645 body. For example, most recipients need to know the values of <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> and <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> in order to select a content handler, so placing those fields in a trailer would force the recipient to buffer the entire 1632 1646 body before it could begin, greatly increasing user-perceived latency and defeating one of the main advantages of using chunked 1633 1647 to send data streams of unknown length. A sender <em class="bcp14">MUST NOT</em> generate a trailer containing a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, or <a href="#header.trailer" class="smpl">Trailer</a> field. 1634 1648 </p> 1635 <p id="rfc.section.4.1. 1.p.4">A server <em class="bcp14">MUST</em> generate an empty trailer with the chunked transfer coding unless at least one of the following is true:1649 <p id="rfc.section.4.1.2.p.4">A server <em class="bcp14">MUST</em> generate an empty trailer with the chunked transfer coding unless at least one of the following is true: 1636 1650 </p> 1637 1651 <ol> … … 1643 1657 </li> 1644 1658 </ol> 1645 <p id="rfc.section.4.1. 1.p.5">The above requirement prevents the need for an infinite buffer when a message is being received by an HTTP/1.1 (or later)1659 <p id="rfc.section.4.1.2.p.5">The above requirement prevents the need for an infinite buffer when a message is being received by an HTTP/1.1 (or later) 1646 1660 proxy and forwarded to an HTTP/1.0 recipient. 1647 1661 </p> 1648 <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>1649 <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>1650 <div id="rfc.figure.u.3 4"></div><pre class="text"> length := 01662 <h3 id="rfc.section.4.1.3"><a href="#rfc.section.4.1.3">4.1.3</a> <a id="decoding.chunked" href="#decoding.chunked">Decoding Chunked</a></h3> 1663 <p id="rfc.section.4.1.3.p.1">A process for decoding the chunked transfer coding can be represented in pseudo-code as:</p> 1664 <div id="rfc.figure.u.35"></div><pre class="text"> length := 0 1651 1665 read chunk-size, chunk-ext (if any), and CRLF 1652 1666 while (chunk-size > 0) { … … 1664 1678 Remove "chunked" from Transfer-Encoding 1665 1679 Remove Trailer from existing header fields 1666 </pre><p id="rfc.section.4.1.2.p.3">A recipient <em class="bcp14">MUST</em> be able to parse and decode the chunked transfer coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand. 1667 </p> 1668 <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> 1680 </pre><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> 1669 1681 <p id="rfc.section.4.2.p.1">The codings defined below can be used to compress the payload of a message.</p> 1670 1682 <div id="rfc.iref.c.10"></div> … … 1680 1692 </p> 1681 1693 </div> 1682 <div id="rfc.iref.g. 76"></div>1694 <div id="rfc.iref.g.87"></div> 1683 1695 <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> 1684 1696 <p id="rfc.section.4.2.3.p.1">The "gzip" coding is an LZ77 coding with a 32 bit CRC that is commonly produced by the gzip file compression program <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. A recipient <em class="bcp14">SHOULD</em> consider "x-gzip" to be equivalent to "gzip". … … 1692 1704 described in <a href="#transfer.codings" title="Transfer Codings">Section 4</a>), and/or the keyword "trailers". A client <em class="bcp14">MUST NOT</em> send the chunked transfer coding name in TE; chunked is always acceptable for HTTP/1.1 recipients. 1693 1705 </p> 1694 <div id="rfc.figure.u.3 5"></div><pre class="inline"><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span> <a href="#header.te" class="smpl">TE</a> = #<a href="#header.te" class="smpl">t-codings</a>1706 <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span> <a href="#header.te" class="smpl">TE</a> = #<a href="#header.te" class="smpl">t-codings</a> 1695 1707 <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> ] ) 1696 1708 <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> … … 1698 1710 / ( "1" [ "." 0*3("0") ] ) 1699 1711 </pre><p id="rfc.section.4.3.p.4">Three examples of TE use are below.</p> 1700 <div id="rfc.figure.u.3 6"></div><pre class="text"> TE: deflate1712 <div id="rfc.figure.u.37"></div><pre class="text"> TE: deflate 1701 1713 TE: 1702 1714 TE: trailers, deflate;q=0.5 1703 1715 </pre><p id="rfc.section.4.3.p.6">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer 1704 coding, as defined in <a href="#chunked.trailer.part" title="Chunked Trailer Part">Section 4.1. 1</a>, on behalf of itself and any downstream clients. For requests from an intermediary, this implies that either: (a) all downstream1716 coding, as defined in <a href="#chunked.trailer.part" title="Chunked Trailer Part">Section 4.1.2</a>, on behalf of itself and any downstream clients. For requests from an intermediary, this implies that either: (a) all downstream 1705 1717 clients are willing to accept trailer fields in the forwarded response; or, (b) the intermediary will attempt to buffer the 1706 1718 response on behalf of downstream recipients. Note that HTTP/1.1 does not define any means to limit the size of a chunked response … … 1723 1735 and the recipient wishes to confirm an integrity check on the fly. 1724 1736 </p> 1725 <div id="rfc.figure.u.3 7"></div><pre class="inline"><span id="rfc.iref.g.81"></span> <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>1737 <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.92"></span> <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a> 1726 1738 </pre><h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="message.routing" href="#message.routing">Message Routing</a></h1> 1727 1739 <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, … … 1762 1774 both the method being requested and whether the request is to a proxy. 1763 1775 </p> 1764 <div id="rfc.figure.u.3 8"></div><pre class="inline"><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span> <a href="#request-target" class="smpl">request-target</a> = <a href="#origin-form" class="smpl">origin-form</a>1776 <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.93"></span><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span> <a href="#request-target" class="smpl">request-target</a> = <a href="#origin-form" class="smpl">origin-form</a> 1765 1777 / <a href="#absolute-form" class="smpl">absolute-form</a> 1766 1778 / <a href="#authority-form" class="smpl">authority-form</a> … … 1780 1792 </p> 1781 1793 <p id="rfc.section.5.3.p.5">For example, a client wishing to retrieve a representation of the resource identified as</p> 1782 <div id="rfc.figure.u. 39"></div><pre class="text">http://www.example.org/where?q=now1794 <div id="rfc.figure.u.40"></div><pre class="text">http://www.example.org/where?q=now 1783 1795 </pre><p id="rfc.section.5.3.p.7">directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and send the 1784 1796 lines: 1785 1797 </p> 1786 <div id="rfc.figure.u.4 0"></div><pre class="text2">GET /where?q=now HTTP/1.11798 <div id="rfc.figure.u.41"></div><pre class="text2">GET /where?q=now HTTP/1.1 1787 1799 Host: www.example.org 1788 1800 </pre><p id="rfc.section.5.3.p.9">followed by the remainder of the request message.</p> … … 1796 1808 </p> 1797 1809 <p id="rfc.section.5.3.p.12">An example absolute-form of request-line would be:</p> 1798 <div id="rfc.figure.u.4 1"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.11810 <div id="rfc.figure.u.42"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1799 1811 </pre><p id="rfc.section.5.3.p.14">To allow for transition to the absolute-form for all requests in some future version of HTTP, a server <em class="bcp14">MUST</em> accept the absolute-form in requests, even though HTTP/1.1 clients will only send them in requests to proxies. 1800 1812 </p> … … 1805 1817 <p id="rfc.section.5.3.p.16">The <dfn>authority-form</dfn> of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo and its "@" delimiter) as the request-target. For example, 1806 1818 </p> 1807 <div id="rfc.figure.u.4 2"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.11819 <div id="rfc.figure.u.43"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1 1808 1820 </pre><div id="asterisk-form"> 1809 1821 <p id="rfc.section.5.3.p.18"><span id="rfc.iref.a.4"></span> <b>asterisk-form</b> … … 1813 1825 the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example, 1814 1826 </p> 1815 <div id="rfc.figure.u.4 3"></div><pre class="text2">OPTIONS * HTTP/1.11827 <div id="rfc.figure.u.44"></div><pre class="text2">OPTIONS * HTTP/1.1 1816 1828 </pre><p id="rfc.section.5.3.p.21">If a proxy receives an OPTIONS request with an absolute-form of request-target in which the URI has an empty path and no query 1817 1829 component, then the last proxy on the request chain <em class="bcp14">MUST</em> send a request-target of "*" when it forwards the request to the indicated origin server. 1818 1830 </p> 1819 <div id="rfc.figure.u.4 4"></div>1831 <div id="rfc.figure.u.45"></div> 1820 1832 <p>For example, the request</p><pre class="text2">OPTIONS http://www.example.org:8001 HTTP/1.1 1821 </pre><div id="rfc.figure.u.4 5"></div>1833 </pre><div id="rfc.figure.u.46"></div> 1822 1834 <p>would be forwarded by the final proxy as</p><pre class="text2">OPTIONS * HTTP/1.1 1823 1835 Host: www.example.org:8001 … … 1828 1840 to distinguish among resources while servicing requests for multiple host names on a single IP address. 1829 1841 </p> 1830 <div id="rfc.figure.u.4 6"></div><pre class="inline"><span id="rfc.iref.g.87"></span> <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 2.7.1</a>1842 <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.98"></span> <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 2.7.1</a> 1831 1843 </pre><p id="rfc.section.5.4.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target URI includes an authority component, then a client <em class="bcp14">MUST</em> send a field-value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" 1832 1844 delimiter (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>). If the authority component is missing or undefined for the target URI, then a client <em class="bcp14">MUST</em> send a Host header field with an empty field-value. … … 1835 1847 </p> 1836 1848 <p id="rfc.section.5.4.p.5">For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with:</p> 1837 <div id="rfc.figure.u.4 7"></div><pre class="text2">GET /pub/WWW/ HTTP/1.11849 <div id="rfc.figure.u.48"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1 1838 1850 Host: www.example.org 1839 1851 </pre><p id="rfc.section.5.4.p.7">A client <em class="bcp14">MUST</em> send a Host header field in an HTTP/1.1 request even if the request-target is in the absolute-form, since this allows the … … 1874 1886 the scheme, "://", authority, and combined path and query component. 1875 1887 </p> 1876 <div id="rfc.figure.u.4 8"></div>1888 <div id="rfc.figure.u.49"></div> 1877 1889 <p>Example 1: the following message received over an insecure TCP connection</p><pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1 1878 1890 Host: www.example.org:8080 1879 </pre><div id="rfc.figure.u. 49"></div>1891 </pre><div id="rfc.figure.u.50"></div> 1880 1892 <p>has an effective request URI of</p><pre class="text">http://www.example.org:8080/pub/WWW/TheProject.html 1881 </pre><div id="rfc.figure.u.5 0"></div>1893 </pre><div id="rfc.figure.u.51"></div> 1882 1894 <p>Example 2: the following message received over a TLS-secured TCP connection</p><pre class="text">OPTIONS * HTTP/1.1 1883 1895 Host: www.example.org 1884 </pre><div id="rfc.figure.u.5 1"></div>1896 </pre><div id="rfc.figure.u.52"></div> 1885 1897 <p>has an effective request URI of</p><pre class="text">https://www.example.org 1886 1898 </pre><p id="rfc.section.5.5.p.12">An origin server that does not allow resources to differ by requested host <em class="bcp14">MAY</em> ignore the <a href="#header.host" class="smpl">Host</a> field-value and instead replace it with a configured server name when constructing the effective request URI. … … 1915 1927 along the request/response chain. 1916 1928 </p> 1917 <div id="rfc.figure.u.5 2"></div><pre class="inline"><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span> <a href="#header.via" class="smpl">Via</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )1929 <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.99"></span><span id="rfc.iref.g.100"></span><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></span><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span> <a href="#header.via" class="smpl">Via</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) 1918 1930 1919 1931 <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.upgrade" class="smpl">protocol-name</a> "/" ] <a href="#header.upgrade" class="smpl">protocol-version</a> … … 1941 1953 server at www.example.com. The request received by www.example.com would then have the following Via header field: 1942 1954 </p> 1943 <div id="rfc.figure.u.5 3"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net1955 <div id="rfc.figure.u.54"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net 1944 1956 </pre><p id="rfc.section.5.7.1.p.10">An intermediary used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em> forward the names and ports of hosts within the firewall region unless it is explicitly enabled to do so. If not enabled, 1945 1957 such an intermediary <em class="bcp14">SHOULD</em> replace each received-by host of any host behind the firewall by an appropriate pseudonym for that host. … … 1948 1960 values. For example, 1949 1961 </p> 1950 <div id="rfc.figure.u.5 4"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy1962 <div id="rfc.figure.u.55"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 1951 1963 </pre><p id="rfc.section.5.7.1.p.13">could be collapsed to</p> 1952 <div id="rfc.figure.u.5 5"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy1964 <div id="rfc.figure.u.56"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 1953 1965 </pre><p id="rfc.section.5.7.1.p.15">A sender <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced 1954 1966 by pseudonyms. A sender <em class="bcp14">MUST NOT</em> combine entries that have different received-protocol values. … … 2006 2018 </p> 2007 2019 <p id="rfc.section.6.1.p.4">The Connection header field's value has the following grammar:</p> 2008 <div id="rfc.figure.u.5 6"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-option</a>2020 <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-option</a> 2009 2021 <a href="#header.connection" class="smpl">connection-option</a> = <a href="#rule.token.separators" class="smpl">token</a> 2010 2022 </pre><p id="rfc.section.6.1.p.6">Connection options are case-insensitive.</p> … … 2026 2038 For example, 2027 2039 </p> 2028 <div id="rfc.figure.u.5 7"></div><pre class="text"> Connection: close2040 <div id="rfc.figure.u.58"></div><pre class="text"> Connection: close 2029 2041 </pre><p id="rfc.section.6.1.p.12">in either the request or the response header fields indicates that the sender is going to close the connection after the current 2030 2042 request/response is complete (<a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.1" title="Tear-down">Section 6.6</a>). … … 2161 2173 in order of descending preference, before sending the final response. A server <em class="bcp14">MAY</em> ignore a received Upgrade header field if it wishes to continue using the current protocol on that connection. 2162 2174 </p> 2163 <div id="rfc.figure.u.5 8"></div><pre class="inline"><span id="rfc.iref.g.96"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#header.upgrade" class="smpl">protocol</a>2175 <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.107"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#header.upgrade" class="smpl">protocol</a> 2164 2176 2165 2177 <a href="#header.upgrade" class="smpl">protocol</a> = <a href="#header.upgrade" class="smpl">protocol-name</a> ["/" <a href="#header.upgrade" class="smpl">protocol-version</a>] … … 2175 2187 in order of descending preference, when appropriate for a future request. 2176 2188 </p> 2177 <div id="rfc.figure.u. 59"></div>2189 <div id="rfc.figure.u.60"></div> 2178 2190 <p>The following is a hypothetical example sent by a client:</p><pre class="text2">GET /hello.txt HTTP/1.1 2179 2191 Host: www.example.com … … 2193 2205 by any protocol. 2194 2206 </p> 2195 <div id="rfc.figure.u.6 0"></div>2207 <div id="rfc.figure.u.61"></div> 2196 2208 <p>The following is an example response to the above hypothetical request:</p><pre class="text">HTTP/1.1 101 Switching Protocols 2197 2209 Connection: upgrade … … 2217 2229 indicating at least <n> and at most <m> elements, each separated by a single comma (",") and optional whitespace (OWS). 2218 2230 </p> 2219 <div id="rfc.figure.u.6 1"></div>2231 <div id="rfc.figure.u.62"></div> 2220 2232 <p>Thus, a sender <em class="bcp14">MUST</em> expand the list construct as follows: 2221 2233 </p><pre class="text"> 1#element => element *( OWS "," OWS element ) 2222 </pre><div id="rfc.figure.u.6 2"></div>2234 </pre><div id="rfc.figure.u.63"></div> 2223 2235 <p>and:</p><pre class="text"> #element => [ 1#element ] 2224 </pre><div id="rfc.figure.u.6 3"></div>2236 </pre><div id="rfc.figure.u.64"></div> 2225 2237 <p>and for n >= 1 and m > 1:</p><pre class="text"> <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) 2226 2238 </pre><p id="rfc.section.7.p.6">For compatibility with legacy list rules, a recipient <em class="bcp14">MUST</em> parse and ignore a reasonable number of empty list elements: enough to handle common mistakes by senders that merge values, 2227 2239 but not so much that they could be used as a denial of service mechanism. In other words, a recipient <em class="bcp14">MUST</em> expand the list construct as follows: 2228 2240 </p> 2229 <div id="rfc.figure.u.6 4"></div><pre class="text"> #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]2241 <div id="rfc.figure.u.65"></div><pre class="text"> #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] 2230 2242 2231 2243 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 2232 2244 </pre><p id="rfc.section.7.p.8">Empty elements do not contribute to the count of elements present. For example, given these ABNF productions:</p> 2233 <div id="rfc.figure.u.6 5"></div><pre class="text"> example-list = 1#example-list-elmt2245 <div id="rfc.figure.u.66"></div><pre class="text"> example-list = 1#example-list-elmt 2234 2246 example-list-elmt = token ; see <a href="#field.components" title="Field value components">Section 3.2.6</a> 2235 2247 </pre><p id="rfc.section.7.p.10">Then the following are valid values for example-list (not including the double quotes, which are present for delimitation 2236 2248 only): 2237 2249 </p> 2238 <div id="rfc.figure.u.6 6"></div><pre class="text"> "foo,bar"2250 <div id="rfc.figure.u.67"></div><pre class="text"> "foo,bar" 2239 2251 "foo ,bar," 2240 2252 "foo , ,bar,charlie " 2241 2253 </pre><p id="rfc.section.7.p.12">In contrast, the following values would be invalid, since at least one non-empty element is required by the example-list production:</p> 2242 <div id="rfc.figure.u.6 7"></div><pre class="text"> ""2254 <div id="rfc.figure.u.68"></div><pre class="text"> "" 2243 2255 "," 2244 2256 ", ," … … 3046 3058 </p> 3047 3059 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 3048 <div id="rfc.figure.u.6 8"></div><pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS3060 <div id="rfc.figure.u.69"></div><pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS 3049 3061 3050 3062 <a href="#header.connection" class="smpl">Connection</a> = *( "," OWS ) connection-option *( OWS "," [ OWS … … 3084 3096 <a href="#chunked.encoding" class="smpl">chunk</a> = chunk-size [ chunk-ext ] CRLF chunk-data CRLF 3085 3097 <a href="#chunked.encoding" class="smpl">chunk-data</a> = 1*OCTET 3086 <a href="#chunked.e ncoding" class="smpl">chunk-ext</a> = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )3087 <a href="#chunked.e ncoding" class="smpl">chunk-ext-name</a> = token3088 <a href="#chunked.e ncoding" class="smpl">chunk-ext-val</a> = token / quoted-str-nf3098 <a href="#chunked.extension" class="smpl">chunk-ext</a> = *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) 3099 <a href="#chunked.extension" class="smpl">chunk-ext-name</a> = token 3100 <a href="#chunked.extension" class="smpl">chunk-ext-val</a> = token / quoted-str-nf 3089 3101 <a href="#chunked.encoding" class="smpl">chunk-size</a> = 1*HEXDIG 3090 3102 <a href="#chunked.encoding" class="smpl">chunked-body</a> = *chunk last-chunk trailer-part CRLF … … 3127 3139 / %x5D-7E ; ']'-'~' 3128 3140 / obs-text 3129 <a href="#chunked.e ncoding" class="smpl">qdtext-nf</a> = HTAB / SP / "!" / %x23-5B ; '#'-'['3141 <a href="#chunked.extension" class="smpl">qdtext-nf</a> = HTAB / SP / "!" / %x23-5B ; '#'-'[' 3130 3142 / %x5D-7E ; ']'-'~' 3131 3143 / obs-text … … 3133 3145 <a href="#rule.quoted-cpair" class="smpl">quoted-cpair</a> = "\" ( HTAB / SP / VCHAR / obs-text ) 3134 3146 <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> = "\" ( HTAB / SP / VCHAR / obs-text ) 3135 <a href="#chunked.e ncoding" class="smpl">quoted-str-nf</a> = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE3147 <a href="#chunked.extension" class="smpl">quoted-str-nf</a> = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE 3136 3148 <a href="#rule.quoted-string" class="smpl">quoted-string</a> = DQUOTE *( qdtext / quoted-pair ) DQUOTE 3137 3149 … … 3256 3268 <p id="rfc.section.C.4.p.1">Closed issues: </p> 3257 3269 <ul> 3258 <li><<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/343">http://tools.ietf.org/wg/httpbis/trac/ticket/343</a>>: "chunk-extensions" ( removed the earlier deprecation)3270 <li><<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/343">http://tools.ietf.org/wg/httpbis/trac/ticket/343</a>>: "chunk-extensions" (un-deprecated and explained) 3259 3271 </li> 3260 3272 <li><<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/483">http://tools.ietf.org/wg/httpbis/trac/ticket/483</a>>: "MUST fix Content-Length?" … … 3309 3321 <li><tt>Grammar</tt> 3310 3322 <ul> 3311 <li><tt>absolute-form</tt> <a href="#rfc.iref.g. 84"><b>5.3</b></a></li>3323 <li><tt>absolute-form</tt> <a href="#rfc.iref.g.95"><b>5.3</b></a></li> 3312 3324 <li><tt>absolute-path</tt> <a href="#rfc.iref.g.19"><b>2.7</b></a></li> 3313 3325 <li><tt>absolute-URI</tt> <a href="#rfc.iref.g.17"><b>2.7</b></a></li> 3314 3326 <li>ALPHA <a href="#rfc.iref.g.1"><b>1.2</b></a></li> 3315 <li><tt>asterisk-form</tt> <a href="#rfc.iref.g. 86"><b>5.3</b></a></li>3327 <li><tt>asterisk-form</tt> <a href="#rfc.iref.g.97"><b>5.3</b></a></li> 3316 3328 <li><tt>attribute</tt> <a href="#rfc.iref.g.60"><b>4</b></a></li> 3317 3329 <li><tt>authority</tt> <a href="#rfc.iref.g.18"><b>2.7</b></a></li> 3318 <li><tt>authority-form</tt> <a href="#rfc.iref.g. 85"><b>5.3</b></a></li>3330 <li><tt>authority-form</tt> <a href="#rfc.iref.g.96"><b>5.3</b></a></li> 3319 3331 <li><tt>BWS</tt> <a href="#rfc.iref.g.42"><b>3.2.3</b></a></li> 3320 <li><tt>chunk</tt> <a href="#rfc.iref.g.65"><b>4.1</b></a> </li>3321 <li><tt>chunk-data</tt> <a href="#rfc.iref.g.71"><b>4.1</b></a> </li>3322 <li><tt>chunk-ext</tt> <a href="#rfc.iref.g.68"><b>4.1</b></a> </li>3323 <li><tt>chunk-ext-name</tt> <a href="#rfc.iref.g.69"><b>4.1</b></a> </li>3324 <li><tt>chunk-ext-val</tt> <a href="#rfc.iref.g.70"><b>4.1</b></a> </li>3325 <li><tt>chunk-size</tt> <a href="#rfc.iref.g.66"><b>4.1</b></a> </li>3326 <li><tt>chunked-body</tt> <a href="#rfc.iref.g.64"><b>4.1</b></a> </li>3332 <li><tt>chunk</tt> <a href="#rfc.iref.g.65"><b>4.1</b></a>, <a href="#rfc.iref.g.76"><b>4.1.1</b></a></li> 3333 <li><tt>chunk-data</tt> <a href="#rfc.iref.g.71"><b>4.1</b></a>, <a href="#rfc.iref.g.82"><b>4.1.1</b></a></li> 3334 <li><tt>chunk-ext</tt> <a href="#rfc.iref.g.68"><b>4.1</b></a>, <a href="#rfc.iref.g.79"><b>4.1.1</b></a></li> 3335 <li><tt>chunk-ext-name</tt> <a href="#rfc.iref.g.69"><b>4.1</b></a>, <a href="#rfc.iref.g.80"><b>4.1.1</b></a></li> 3336 <li><tt>chunk-ext-val</tt> <a href="#rfc.iref.g.70"><b>4.1</b></a>, <a href="#rfc.iref.g.81"><b>4.1.1</b></a></li> 3337 <li><tt>chunk-size</tt> <a href="#rfc.iref.g.66"><b>4.1</b></a>, <a href="#rfc.iref.g.77"><b>4.1.1</b></a></li> 3338 <li><tt>chunked-body</tt> <a href="#rfc.iref.g.64"><b>4.1</b></a>, <a href="#rfc.iref.g.75"><b>4.1.1</b></a></li> 3327 3339 <li><tt>comment</tt> <a href="#rfc.iref.g.51"><b>3.2.6</b></a></li> 3328 <li><tt>Connection</tt> <a href="#rfc.iref.g. 94"><b>6.1</b></a></li>3329 <li><tt>connection-option</tt> <a href="#rfc.iref.g. 95"><b>6.1</b></a></li>3340 <li><tt>Connection</tt> <a href="#rfc.iref.g.105"><b>6.1</b></a></li> 3341 <li><tt>connection-option</tt> <a href="#rfc.iref.g.106"><b>6.1</b></a></li> 3330 3342 <li><tt>Content-Length</tt> <a href="#rfc.iref.g.56"><b>3.3.2</b></a></li> 3331 3343 <li>CR <a href="#rfc.iref.g.2"><b>1.2</b></a></li> … … 3343 3355 <li><tt>header-field</tt> <a href="#rfc.iref.g.35"><b>3.2</b></a></li> 3344 3356 <li>HEXDIG <a href="#rfc.iref.g.7"><b>1.2</b></a></li> 3345 <li><tt>Host</tt> <a href="#rfc.iref.g. 87"><b>5.4</b></a></li>3357 <li><tt>Host</tt> <a href="#rfc.iref.g.98"><b>5.4</b></a></li> 3346 3358 <li>HTAB <a href="#rfc.iref.g.8"><b>1.2</b></a></li> 3347 3359 <li><tt>HTTP-message</tt> <a href="#rfc.iref.g.28"><b>3</b></a></li> … … 3350 3362 <li><tt>HTTP-version</tt> <a href="#rfc.iref.g.14"><b>2.6</b></a></li> 3351 3363 <li><tt>https-URI</tt> <a href="#rfc.iref.g.27"><b>2.7.2</b></a></li> 3352 <li><tt>last-chunk</tt> <a href="#rfc.iref.g.67"><b>4.1</b></a> </li>3364 <li><tt>last-chunk</tt> <a href="#rfc.iref.g.67"><b>4.1</b></a>, <a href="#rfc.iref.g.78"><b>4.1.1</b></a></li> 3353 3365 <li>LF <a href="#rfc.iref.g.9"><b>1.2</b></a></li> 3354 3366 <li><tt>message-body</tt> <a href="#rfc.iref.g.54"><b>3.3</b></a></li> … … 3357 3369 <li><tt>obs-text</tt> <a href="#rfc.iref.g.49"><b>3.2.6</b></a></li> 3358 3370 <li>OCTET <a href="#rfc.iref.g.10"><b>1.2</b></a></li> 3359 <li><tt>origin-form</tt> <a href="#rfc.iref.g. 83"><b>5.3</b></a></li>3371 <li><tt>origin-form</tt> <a href="#rfc.iref.g.94"><b>5.3</b></a></li> 3360 3372 <li><tt>OWS</tt> <a href="#rfc.iref.g.40"><b>3.2.3</b></a></li> 3361 3373 <li><tt>partial-URI</tt> <a href="#rfc.iref.g.25"><b>2.7</b></a></li> 3362 3374 <li><tt>port</tt> <a href="#rfc.iref.g.20"><b>2.7</b></a></li> 3363 <li><tt>protocol-name</tt> <a href="#rfc.iref.g. 90"><b>5.7.1</b></a></li>3364 <li><tt>protocol-version</tt> <a href="#rfc.iref.g. 91"><b>5.7.1</b></a></li>3365 <li><tt>pseudonym</tt> <a href="#rfc.iref.g. 93"><b>5.7.1</b></a></li>3375 <li><tt>protocol-name</tt> <a href="#rfc.iref.g.101"><b>5.7.1</b></a></li> 3376 <li><tt>protocol-version</tt> <a href="#rfc.iref.g.102"><b>5.7.1</b></a></li> 3377 <li><tt>pseudonym</tt> <a href="#rfc.iref.g.104"><b>5.7.1</b></a></li> 3366 3378 <li><tt>qdtext</tt> <a href="#rfc.iref.g.48"><b>3.2.6</b></a></li> 3367 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.74"><b>4.1</b></a> </li>3379 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.74"><b>4.1</b></a>, <a href="#rfc.iref.g.85"><b>4.1.1</b></a></li> 3368 3380 <li><tt>query</tt> <a href="#rfc.iref.g.21"><b>2.7</b></a></li> 3369 3381 <li><tt>quoted-cpair</tt> <a href="#rfc.iref.g.53"><b>3.2.6</b></a></li> 3370 3382 <li><tt>quoted-pair</tt> <a href="#rfc.iref.g.50"><b>3.2.6</b></a></li> 3371 <li><tt>quoted-str-nf</tt> <a href="#rfc.iref.g.73"><b>4.1</b></a> </li>3383 <li><tt>quoted-str-nf</tt> <a href="#rfc.iref.g.73"><b>4.1</b></a>, <a href="#rfc.iref.g.84"><b>4.1.1</b></a></li> 3372 3384 <li><tt>quoted-string</tt> <a href="#rfc.iref.g.47"><b>3.2.6</b></a></li> 3373 <li><tt>rank</tt> <a href="#rfc.iref.g. 80"><b>4.3</b></a></li>3385 <li><tt>rank</tt> <a href="#rfc.iref.g.91"><b>4.3</b></a></li> 3374 3386 <li><tt>reason-phrase</tt> <a href="#rfc.iref.g.34"><b>3.1.2</b></a></li> 3375 <li><tt>received-by</tt> <a href="#rfc.iref.g. 92"><b>5.7.1</b></a></li>3376 <li><tt>received-protocol</tt> <a href="#rfc.iref.g. 89"><b>5.7.1</b></a></li>3387 <li><tt>received-by</tt> <a href="#rfc.iref.g.103"><b>5.7.1</b></a></li> 3388 <li><tt>received-protocol</tt> <a href="#rfc.iref.g.100"><b>5.7.1</b></a></li> 3377 3389 <li><tt>request-line</tt> <a href="#rfc.iref.g.30"><b>3.1.1</b></a></li> 3378 <li><tt>request-target</tt> <a href="#rfc.iref.g. 82"><b>5.3</b></a></li>3390 <li><tt>request-target</tt> <a href="#rfc.iref.g.93"><b>5.3</b></a></li> 3379 3391 <li><tt>RWS</tt> <a href="#rfc.iref.g.41"><b>3.2.3</b></a></li> 3380 3392 <li><tt>segment</tt> <a href="#rfc.iref.g.23"><b>2.7</b></a></li> … … 3384 3396 <li><tt>status-code</tt> <a href="#rfc.iref.g.33"><b>3.1.2</b></a></li> 3385 3397 <li><tt>status-line</tt> <a href="#rfc.iref.g.32"><b>3.1.2</b></a></li> 3386 <li><tt>t-codings</tt> <a href="#rfc.iref.g. 78"><b>4.3</b></a></li>3387 <li><tt>t-ranking</tt> <a href="#rfc.iref.g. 79"><b>4.3</b></a></li>3398 <li><tt>t-codings</tt> <a href="#rfc.iref.g.89"><b>4.3</b></a></li> 3399 <li><tt>t-ranking</tt> <a href="#rfc.iref.g.90"><b>4.3</b></a></li> 3388 3400 <li><tt>tchar</tt> <a href="#rfc.iref.g.45"><b>3.2.6</b></a></li> 3389 <li><tt>TE</tt> <a href="#rfc.iref.g. 77"><b>4.3</b></a></li>3401 <li><tt>TE</tt> <a href="#rfc.iref.g.88"><b>4.3</b></a></li> 3390 3402 <li><tt>token</tt> <a href="#rfc.iref.g.44"><b>3.2.6</b></a></li> 3391 <li><tt>Trailer</tt> <a href="#rfc.iref.g. 81"><b>4.4</b></a></li>3392 <li><tt>trailer-part</tt> <a href="#rfc.iref.g.72">4.1</a>, <a href="#rfc.iref.g. 75"><b>4.1.1</b></a></li>3403 <li><tt>Trailer</tt> <a href="#rfc.iref.g.92"><b>4.4</b></a></li> 3404 <li><tt>trailer-part</tt> <a href="#rfc.iref.g.72">4.1</a>, <a href="#rfc.iref.g.83">4.1.1</a>, <a href="#rfc.iref.g.86"><b>4.1.2</b></a></li> 3393 3405 <li><tt>transfer-coding</tt> <a href="#rfc.iref.g.57"><b>4</b></a></li> 3394 3406 <li><tt>Transfer-Encoding</tt> <a href="#rfc.iref.g.55"><b>3.3.1</b></a></li> 3395 3407 <li><tt>transfer-extension</tt> <a href="#rfc.iref.g.58"><b>4</b></a></li> 3396 3408 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.59"><b>4</b></a></li> 3397 <li><tt>Upgrade</tt> <a href="#rfc.iref.g. 96"><b>6.7</b></a></li>3409 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.107"><b>6.7</b></a></li> 3398 3410 <li><tt>uri-host</tt> <a href="#rfc.iref.g.24"><b>2.7</b></a></li> 3399 3411 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.16"><b>2.7</b></a></li> 3400 3412 <li><tt>value</tt> <a href="#rfc.iref.g.61"><b>4</b></a></li> 3401 3413 <li>VCHAR <a href="#rfc.iref.g.12"><b>1.2</b></a></li> 3402 <li><tt>Via</tt> <a href="#rfc.iref.g. 88"><b>5.7.1</b></a></li>3414 <li><tt>Via</tt> <a href="#rfc.iref.g.99"><b>5.7.1</b></a></li> 3403 3415 <li><tt>word</tt> <a href="#rfc.iref.g.43"><b>3.2.6</b></a></li> 3404 3416 </ul> 3405 3417 </li> 3406 <li>gzip (Coding Format) <a href="#rfc.iref.g. 76">4.2.3</a></li>3418 <li>gzip (Coding Format) <a href="#rfc.iref.g.87">4.2.3</a></li> 3407 3419 </ul> 3408 3420 </li> … … 3569 3581 <li>target resource <a href="#rfc.iref.t.7"><b>5.1</b></a></li> 3570 3582 <li>target URI <a href="#rfc.iref.t.8"><b>5.1</b></a></li> 3571 <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.5"><b>4.3</b></a>, <a href="#rfc.xref.header.te.3">8.1</a></li>3583 <li>TE header field <a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1.2</a>, <a href="#rfc.iref.t.5"><b>4.3</b></a>, <a href="#rfc.xref.header.te.3">8.1</a></li> 3572 3584 <li>Trailer header field <a href="#rfc.iref.t.6"><b>4.4</b></a>, <a href="#rfc.xref.header.trailer.1">8.1</a></li> 3573 3585 <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">8.1</a>, <a href="#rfc.xref.header.transfer-encoding.4">A.1.3</a></li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r2405 r2406 1978 1978 <x:anchor-alias value="chunked-body"/> 1979 1979 <x:anchor-alias value="chunk-data"/> 1980 <x:anchor-alias value="chunk-ext"/>1981 <x:anchor-alias value="chunk-ext-name"/>1982 <x:anchor-alias value="chunk-ext-val"/>1983 1980 <x:anchor-alias value="chunk-size"/> 1984 1981 <x:anchor-alias value="last-chunk"/> 1985 <x:anchor-alias value="quoted-str-nf"/> 1986 <x:anchor-alias value="qdtext-nf"/> 1987 <t> 1988 The chunked transfer coding modifies the body of a message in order to 1989 transfer it as a series of chunks, each with its own size indicator, 1990 followed by an &OPTIONAL; trailer containing header fields. This 1991 allows dynamically generated content to be transferred along with the 1992 information necessary for the recipient to verify that it has 1993 received the full message. 1982 <t> 1983 The chunked transfer coding wraps the payload body in order to transfer it 1984 as a series of chunks, each with its own size indicator, followed by an 1985 &OPTIONAL; trailer containing header fields. Chunked enables content 1986 streams of unknown size to be transferred as a sequence of length-delimited 1987 buffers, which enables the sender to retain connection persistence and the 1988 recipient to know when it has received the entire message. 1994 1989 </t> 1995 1990 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="chunked-body"><!--terminal production--></iref><iref primary="true" item="Grammar" subitem="chunk"/><iref primary="true" item="Grammar" subitem="chunk-size"/><iref primary="true" item="Grammar" subitem="last-chunk"/><iref primary="true" item="Grammar" subitem="chunk-ext"/><iref primary="true" item="Grammar" subitem="chunk-ext-name"/><iref primary="true" item="Grammar" subitem="chunk-ext-val"/><iref primary="true" item="Grammar" subitem="chunk-data"/><iref primary="false" item="Grammar" subitem="trailer-part"/><iref primary="true" item="Grammar" subitem="quoted-str-nf"/><iref primary="true" item="Grammar" subitem="qdtext-nf"/> … … 2004 1999 <x:ref>last-chunk</x:ref> = 1*("0") [ <x:ref>chunk-ext</x:ref> ] <x:ref>CRLF</x:ref> 2005 2000 2001 <x:ref>chunk-data</x:ref> = 1*<x:ref>OCTET</x:ref> ; a sequence of chunk-size octets 2002 </artwork></figure> 2003 <t> 2004 The chunk-size field is a string of hex digits indicating the size of 2005 the chunk-data in octets. The chunked transfer coding is complete when a 2006 chunk with a chunk-size of zero is received, possibly followed by a 2007 trailer, and finally terminated by an empty line. 2008 </t> 2009 <t> 2010 A recipient &MUST; be able to parse and decode the chunked transfer coding. 2011 </t> 2012 2013 <section title="Chunk Extensions" anchor="chunked.extension"> 2014 <x:anchor-alias value="chunk-ext"/> 2015 <x:anchor-alias value="chunk-ext-name"/> 2016 <x:anchor-alias value="chunk-ext-val"/> 2017 <x:anchor-alias value="quoted-str-nf"/> 2018 <x:anchor-alias value="qdtext-nf"/> 2019 <t> 2020 The chunked encoding allows each chunk to include zero or more chunk 2021 extensions, immediately following the <x:ref>chunk-size</x:ref>, for the 2022 sake of supplying per-chunk metadata (such as a signature or hash), 2023 mid-message control information, or randomization of message body size. 2024 </t> 2025 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="chunked-body"><!--terminal production--></iref><iref primary="true" item="Grammar" subitem="chunk"/><iref primary="true" item="Grammar" subitem="chunk-size"/><iref primary="true" item="Grammar" subitem="last-chunk"/><iref primary="true" item="Grammar" subitem="chunk-ext"/><iref primary="true" item="Grammar" subitem="chunk-ext-name"/><iref primary="true" item="Grammar" subitem="chunk-ext-val"/><iref primary="true" item="Grammar" subitem="chunk-data"/><iref primary="false" item="Grammar" subitem="trailer-part"/><iref primary="true" item="Grammar" subitem="quoted-str-nf"/><iref primary="true" item="Grammar" subitem="qdtext-nf"/> 2006 2026 <x:ref>chunk-ext</x:ref> = *( ";" <x:ref>chunk-ext-name</x:ref> [ "=" <x:ref>chunk-ext-val</x:ref> ] ) 2027 2007 2028 <x:ref>chunk-ext-name</x:ref> = <x:ref>token</x:ref> 2008 2029 <x:ref>chunk-ext-val</x:ref> = <x:ref>token</x:ref> / <x:ref>quoted-str-nf</x:ref> 2009 <x:ref>chunk-data</x:ref> = 1*<x:ref>OCTET</x:ref> ; a sequence of chunk-size octets2010 2030 2011 2031 <x:ref>quoted-str-nf</x:ref> = <x:ref>DQUOTE</x:ref> *( <x:ref>qdtext-nf</x:ref> / <x:ref>quoted-pair</x:ref> ) <x:ref>DQUOTE</x:ref> … … 2014 2034 </artwork></figure> 2015 2035 <t> 2016 Chunk extensions need to be used carefully because use of chunking does not 2017 have any semantics related to the message; it is by definition hop-by-hop 2018 and thus can be removed/reformatted by any intermediary. 2019 Furthermore, few implementations expose information about their contents. 2020 </t> 2021 <t> 2022 The chunk-size field is a string of hex digits indicating the size of 2023 the chunk-data in octets. The chunked transfer coding is complete when a 2024 chunk with a chunk-size of zero is received, possibly followed by a 2025 trailer, and finally terminated by an empty line. 2026 </t> 2036 The chunked encoding is specific to each connection and is likely to be 2037 removed or recoded by each recipient (including intermediaries) before any 2038 higher-level application would have a chance to inspect the extensions. 2039 Hence, use of chunk extensions is generally limited to specialized HTTP 2040 services such as "long polling" (where client and server can have shared 2041 expectations regarding the use of chunk extensions) or for padding within 2042 an end-to-end secured connection. 2043 </t> 2044 <t> 2045 A recipient &MUST; ignore unrecognized chunk extensions. 2046 A server ought to limit the total length of chunk extensions received in a 2047 request to an amount reasonable for the services provided, in the same way 2048 that it applies length limitations and timeouts for other parts of a 2049 message, and generate an appropriate <x:ref>4xx (Client Error)</x:ref> 2050 response if that amount is exceeded. 2051 </t> 2052 </section> 2027 2053 2028 2054 <section title="Chunked Trailer Part" anchor="chunked.trailer.part"> … … 2098 2124 Remove Trailer from existing header fields 2099 2125 </artwork></figure> 2100 <t>2101 A recipient &MUST; be able to parse and decode the2102 chunked transfer coding and &MUST; ignore chunk-ext extensions2103 they do not understand.2104 </t>2105 2126 </section> 2106 2127 </section> … … 5493 5514 <t> 5494 5515 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/343"/>: 5495 "chunk-extensions" ( removed the earlier deprecation)5516 "chunk-extensions" (un-deprecated and explained) 5496 5517 </t> 5497 5518 <t>
Note: See TracChangeset
for help on using the changeset viewer.