Changeset 1831 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 19/08/12 09:46:53 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1830 r1831 626 626 </ul> 627 627 </li> 628 <li><a href="#rfc.section.4.3">4.3</a> <a href="#header.te">TE</a><ul> 629 <li><a href="#rfc.section.4.3.1">4.3.1</a> <a href="#quality.values">Quality Values</a></li> 630 </ul> 631 </li> 628 <li><a href="#rfc.section.4.3">4.3</a> <a href="#header.te">TE</a></li> 632 629 <li><a href="#rfc.section.4.4">4.4</a> <a href="#header.trailer">Trailer</a></li> 633 630 </ul> … … 1622 1619 <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> 1623 1620 <p id="rfc.section.4.2.p.1">The codings defined below can be used to compress the payload of a message.</p> 1624 <div class="note" id="rfc.section.4.2.p.2">1625 <p> <b>Note:</b> Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings.1626 Their use here is representative of historical practice, not good design.1627 </p>1628 </div>1629 <div class="note" id="rfc.section.4.2.p.3">1630 <p> <b>Note:</b> For compatibility with previous implementations of HTTP, applications <em class="bcp14">SHOULD</em> consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.1631 </p>1632 </div>1633 1621 <div id="rfc.iref.c.9"></div> 1634 1622 <div id="rfc.iref.c.10"></div> 1635 1623 <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a> <a id="compress.coding" href="#compress.coding">Compress Coding</a></h3> 1636 1624 <p id="rfc.section.4.2.1.p.1">The "compress" format is produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch 1637 coding (LZW). 1625 coding (LZW). Recipients <em class="bcp14">SHOULD</em> consider "x-compress" to be equivalent to "compress". 1638 1626 </p> 1639 1627 <div id="rfc.iref.d.2"></div> … … 1649 1637 <div id="rfc.iref.c.12"></div> 1650 1638 <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> 1651 <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. 1639 <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". 1652 1640 </p> 1653 1641 <div id="rfc.iref.t.5"></div> 1654 1642 <div id="rfc.iref.h.8"></div> 1655 1643 <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> 1656 <p id="rfc.section.4.3.p.1">The "TE" header field in dicates what extension transfer-codings the client is willing to accept in the response, and whether1657 or not it is willing to accept trailer fields in a chunked transfer-coding.1658 </p> 1659 <p id="rfc.section.4.3.p.2"> Its value consists of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional1660 accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 4</a>).1644 <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 1645 response, and whether or not the client is willing to accept trailer fields in a chunked transfer-coding. 1646 </p> 1647 <p id="rfc.section.4.3.p.2">The TE field-value consists of a comma-separated list of transfer-coding names, each allowing for optional parameters (as 1648 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. 1661 1649 </p> 1662 1650 <div id="rfc.figure.u.34"></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> 1663 <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#header.te" class="smpl">te-params</a> ] ) 1664 <a href="#header.te" class="smpl">te-params</a> = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> "q=" <a href="#quality.values" class="smpl">qvalue</a> *( <a href="#header.te" class="smpl">te-ext</a> ) 1665 <a href="#header.te" class="smpl">te-ext</a> = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#rule.token.separators" class="smpl">token</a> [ "=" <a href="#rule.token.separators" class="smpl">word</a> ] 1666 </pre><p id="rfc.section.4.3.p.4">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding, 1667 as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding. 1668 </p> 1669 <p id="rfc.section.4.3.p.5">Examples of its use are:</p> 1651 <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 <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> 1653 <a href="#header.te" class="smpl">rank</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] ) 1654 / ( "1" [ "." 0*3("0") ] ) 1655 </pre><p id="rfc.section.4.3.p.4">Three examples of TE use are below.</p> 1670 1656 <div id="rfc.figure.u.35"></div><pre class="text"> TE: deflate 1671 1657 TE: 1672 1658 TE: trailers, deflate;q=0.5 1673 </pre><p id="rfc.section.4.3.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a <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>) whenever TE is present in an HTTP/1.1 message. 1674 </p> 1675 <p id="rfc.section.4.3.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p> 1676 <ol> 1677 <li> 1678 <p>The "chunked" transfer-coding is always acceptable. If the keyword "trailers" is listed, the client indicates that it is willing 1679 to accept trailer fields in the chunked response on behalf of itself and any downstream clients. The implication is that, 1680 if given, the client is stating that either all downstream clients are willing to accept trailer fields in the forwarded response, 1681 or that it will attempt to buffer the response on behalf of downstream recipients. 1682 </p> 1683 <p> <b>Note:</b> HTTP/1.1 does not define any means to limit the size of a chunked response such that a client can be assured of buffering 1684 the entire response. 1685 </p> 1686 </li> 1687 <li> 1688 <p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it 1689 is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section 4.3.1</a>, a qvalue of 0 means "not acceptable".) 1690 </p> 1691 </li> 1692 <li> 1693 <p>If multiple transfer-codings are acceptable, then the acceptable transfer-coding with the highest non-zero qvalue is preferred. 1694 The "chunked" transfer-coding always has a qvalue of 1. 1695 </p> 1696 </li> 1697 </ol> 1698 <p id="rfc.section.4.3.p.9">If the TE field-value is empty or if no TE field is present, the only acceptable transfer-coding is "chunked". A message with 1659 </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-coding, 1660 as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>, on behalf of itself and any downstream clients. For chained requests, this implies that either: (a) all downstream clients 1661 are willing to accept trailer fields in the forwarded response; or, (b) the client will attempt to buffer the response on 1662 behalf of downstream recipients. Note that HTTP/1.1 does not define any means to limit the size of a chunked response such 1663 that a client can be assured of buffering the entire response. 1664 </p> 1665 <p id="rfc.section.4.3.p.7">When multiple transfer-codings are acceptable, the client <em class="bcp14">MAY</em> rank the codings by preference using a "q" parameter (similar to the qvalues used in content negotiation fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 8.3</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred; 1666 a value of 0 means "not acceptable". 1667 </p> 1668 <p id="rfc.section.4.3.p.8">If the TE field-value is empty or if no TE field is present, the only acceptable transfer-coding is "chunked". A message with 1699 1669 no transfer-coding is always acceptable. 1700 1670 </p> 1701 <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a> <a id="quality.values" href="#quality.values">Quality Values</a></h3> 1702 <p id="rfc.section.4.3.1.p.1">Both transfer codings (<a href="#header.te" class="smpl">TE</a> request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight 1703 is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has 1704 a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion. 1705 </p> 1706 <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.78"></span> <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] ) 1707 / ( "1" [ "." 0*3("0") ] ) 1708 </pre><div class="note" id="rfc.section.4.3.1.p.3"> 1709 <p> <b>Note:</b> "Quality values" is a misnomer, since these values merely represent relative degradation in desired quality. 1710 </p> 1711 </div> 1671 <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 </p> 1712 1673 <div id="rfc.iref.t.6"></div> 1713 1674 <div id="rfc.iref.h.9"></div> … … 1716 1677 chunked transfer-coding. 1717 1678 </p> 1718 <div id="rfc.figure.u.3 7"></div><pre class="inline"><span id="rfc.iref.g.79"></span> <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>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> 1719 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 recipient 1720 1681 to know which header fields to expect in the trailer. … … 1767 1728 both the method being requested and whether the request is to a proxy. 1768 1729 </p> 1769 <div id="rfc.figure.u.3 8"></div><pre class="inline"><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> <a href="#request-target" class="smpl">request-target</a> = <a href="#origin-form" class="smpl">origin-form</a>1730 <div id="rfc.figure.u.37"></div><pre class="inline"><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> <a href="#request-target" class="smpl">request-target</a> = <a href="#origin-form" class="smpl">origin-form</a> 1770 1731 / <a href="#absolute-form" class="smpl">absolute-form</a> 1771 1732 / <a href="#authority-form" class="smpl">authority-form</a> … … 1783 1744 </div> 1784 1745 <p id="rfc.section.5.3.p.4">For example, a client wishing to retrieve a representation of the resource identified as</p> 1785 <div id="rfc.figure.u.3 9"></div><pre class="text">http://www.example.org/where?q=now1746 <div id="rfc.figure.u.38"></div><pre class="text">http://www.example.org/where?q=now 1786 1747 </pre><p id="rfc.section.5.3.p.6">directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and send the 1787 1748 lines: 1788 1749 </p> 1789 <div id="rfc.figure.u. 40"></div><pre class="text2">GET /where?q=now HTTP/1.11750 <div id="rfc.figure.u.39"></div><pre class="text2">GET /where?q=now HTTP/1.1 1790 1751 Host: www.example.org 1791 1752 </pre><p id="rfc.section.5.3.p.8">followed by the remainder of the request message.</p> … … 1797 1758 </div> 1798 1759 <p id="rfc.section.5.3.p.10">An example absolute-form of request-line would be:</p> 1799 <div id="rfc.figure.u.4 1"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.11760 <div id="rfc.figure.u.40"></div><pre class="text2">GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1800 1761 </pre><p id="rfc.section.5.3.p.12">To allow for transition to the absolute-form for all requests in some future version of HTTP, HTTP/1.1 servers <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. 1801 1762 </p> … … 1804 1765 </p> 1805 1766 </div> 1806 <div id="rfc.figure.u.4 2"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.11767 <div id="rfc.figure.u.41"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1 1807 1768 </pre><div id="asterisk-form"> 1808 1769 <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 2.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server, … … 1810 1771 </p> 1811 1772 </div> 1812 <div id="rfc.figure.u.4 3"></div><pre class="text2">OPTIONS * HTTP/1.11773 <div id="rfc.figure.u.42"></div><pre class="text2">OPTIONS * HTTP/1.1 1813 1774 </pre><p id="rfc.section.5.3.p.17">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 1814 1775 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. 1815 1776 </p> 1816 <div id="rfc.figure.u.4 4"></div>1777 <div id="rfc.figure.u.43"></div> 1817 1778 <p>For example, the request</p><pre class="text2">OPTIONS http://www.example.org:8001 HTTP/1.1 1818 </pre><div id="rfc.figure.u.4 5"></div>1779 </pre><div id="rfc.figure.u.44"></div> 1819 1780 <p>would be forwarded by the final proxy as</p><pre class="text2">OPTIONS * HTTP/1.1 1820 1781 Host: www.example.org:8001 … … 1827 1788 is critical information for handling a request, it <em class="bcp14">SHOULD</em> be sent as the first header field following the request-line. 1828 1789 </p> 1829 <div id="rfc.figure.u.4 6"></div><pre class="inline"><span id="rfc.iref.g.85"></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.8.1</a>1790 <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.84"></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.8.1</a> 1830 1791 </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 the Host 1831 1792 field-value <em class="bcp14">MUST</em> be identical to that authority component after excluding any userinfo (<a href="#http.uri" title="http URI scheme">Section 2.8.1</a>). If the authority component is missing or undefined for the target URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value. 1832 1793 </p> 1833 1794 <p id="rfc.section.5.4.p.4">For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with:</p> 1834 <div id="rfc.figure.u.4 7"></div><pre class="text2">GET /pub/WWW/ HTTP/1.11795 <div id="rfc.figure.u.46"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1 1835 1796 Host: www.example.org 1836 1797 </pre><p id="rfc.section.5.4.p.6">The Host header field <em class="bcp14">MUST</em> be sent in an HTTP/1.1 request even if the request-target is in the absolute-form, since this allows the Host information … … 1871 1832 the scheme, "://", authority, and combined path and query component. 1872 1833 </p> 1873 <div id="rfc.figure.u.4 8"></div>1834 <div id="rfc.figure.u.47"></div> 1874 1835 <p>Example 1: the following message received over an insecure TCP connection</p> <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1 1875 1836 Host: www.example.org:8080 1837 </pre> <div id="rfc.figure.u.48"></div> 1838 <p>has an effective request URI of</p> <pre class="text">http://www.example.org:8080/pub/WWW/TheProject.html 1876 1839 </pre> <div id="rfc.figure.u.49"></div> 1877 <p>has an effective request URI of</p> <pre class="text">http://www.example.org:8080/pub/WWW/TheProject.html1878 </pre> <div id="rfc.figure.u.50"></div>1879 1840 <p>Example 2: the following message received over an SSL/TLS-secured TCP connection</p> <pre class="text">OPTIONS * HTTP/1.1 1880 1841 Host: www.example.org 1881 </pre> <div id="rfc.figure.u.5 1"></div>1842 </pre> <div id="rfc.figure.u.50"></div> 1882 1843 <p>has an effective request URI of</p> <pre class="text">https://www.example.org 1883 1844 </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. … … 1994 1955 </p> 1995 1956 <p id="rfc.section.6.1.p.2">The Connection header field's value has the following grammar:</p> 1996 <div id="rfc.figure.u.5 2"></div><pre class="inline"><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-option</a>1957 <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-option</a> 1997 1958 <a href="#header.connection" class="smpl">connection-option</a> = <a href="#rule.token.separators" class="smpl">token</a> 1998 1959 </pre><p id="rfc.section.6.1.p.4">Connection options are compared case-insensitively.</p> … … 2019 1980 of the response. For example, 2020 1981 </p> 2021 <div id="rfc.figure.u.5 3"></div><pre class="text"> Connection: close1982 <div id="rfc.figure.u.52"></div><pre class="text"> Connection: close 2022 1983 </pre><p id="rfc.section.6.1.p.11">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered "persistent" (<a href="#persistent.connections" title="Persistent Connections">Section 6.3</a>) after the current request/response is complete. 2023 1984 </p> … … 2034 1995 of all senders along the request/response chain. 2035 1996 </p> 2036 <div id="rfc.figure.u.5 4"></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>1997 <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.87"></span><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> <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> 2037 1998 [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) 2038 1999 <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> … … 2055 2016 server at www.example.com. The request received by www.example.com would then have the following Via header field: 2056 2017 </p> 2057 <div id="rfc.figure.u.5 5"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)2018 <div id="rfc.figure.u.54"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2058 2019 </pre><p id="rfc.section.6.2.p.9">A proxy or gateway 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, 2059 2020 the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. … … 2062 2023 values. For example, 2063 2024 </p> 2064 <div id="rfc.figure.u.5 6"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy2025 <div id="rfc.figure.u.55"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2065 2026 </pre><p id="rfc.section.6.2.p.12">could be collapsed to</p> 2066 <div id="rfc.figure.u.5 7"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy2027 <div id="rfc.figure.u.56"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2067 2028 </pre><p id="rfc.section.6.2.p.14">Senders <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 2068 2029 by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. … … 2226 2187 server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to. 2227 2188 </p> 2228 <div id="rfc.figure.u.5 8"></div><pre class="inline"><span id="rfc.iref.g.94"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#header.upgrade" class="smpl">protocol</a>2189 <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.93"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#header.upgrade" class="smpl">protocol</a> 2229 2190 2230 2191 <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>] … … 2232 2193 <a href="#header.upgrade" class="smpl">protocol-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 2233 2194 </pre><p id="rfc.section.6.5.p.3">For example,</p> 2234 <div id="rfc.figure.u.5 9"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x112195 <div id="rfc.figure.u.58"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2235 2196 </pre><p id="rfc.section.6.5.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible 2236 2197 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP … … 2301 2262 <td class="left">http</td> 2302 2263 <td class="left">standard</td> 2303 <td class="left"> <a href="#header.te" id="rfc.xref.header.te. 4" title="TE">Section 4.3</a>2264 <td class="left"> <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 4.3</a> 2304 2265 </td> 2305 2266 </tr> … … 2512 2473 <li>Pointer to specification text</li> 2513 2474 </ul> 2514 <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>. 2515 </p> 2516 <p id="rfc.section.7.4.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section. 2475 <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>. 2476 </p> 2477 <p id="rfc.section.7.4.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section. Use of program names for the identification of encoding 2478 formats is not desirable and is discouraged for future encodings. 2517 2479 </p> 2518 2480 <p id="rfc.section.7.4.p.5">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. … … 3016 2978 indicating at least <n> and at most <m> elements, each separated by a single comma (",") and optional whitespace (OWS). 3017 2979 </p> 3018 <div id="rfc.figure.u. 60"></div>2980 <div id="rfc.figure.u.59"></div> 3019 2981 <p>Thus,</p><pre class="text"> 1#element => element *( OWS "," OWS element ) 2982 </pre><div id="rfc.figure.u.60"></div> 2983 <p>and:</p><pre class="text"> #element => [ 1#element ] 3020 2984 </pre><div id="rfc.figure.u.61"></div> 3021 <p>and:</p><pre class="text"> #element => [ 1#element ]3022 </pre><div id="rfc.figure.u.62"></div>3023 2985 <p>and for n >= 1 and m > 1:</p><pre class="text"> <n>#<m>element => element <n-1>*<m-1>( OWS "," OWS element ) 3024 2986 </pre><p id="rfc.section.B.p.6">For compatibility with legacy list rules, recipients <em class="bcp14">SHOULD</em> accept empty list elements. In other words, consumers would follow the list productions: 3025 2987 </p> 3026 <div id="rfc.figure.u.6 3"></div><pre class="text"> #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ]2988 <div id="rfc.figure.u.62"></div><pre class="text"> #element => [ ( "," / element ) *( OWS "," [ OWS element ] ) ] 3027 2989 3028 2990 1#element => *( "," OWS ) element *( OWS "," [ OWS element ] ) 3029 2991 </pre><p id="rfc.section.B.p.8">Note that empty elements do not contribute to the count of elements present, though.</p> 3030 2992 <p id="rfc.section.B.p.9">For example, given these ABNF productions:</p> 3031 <div id="rfc.figure.u.6 4"></div><pre class="text"> example-list = 1#example-list-elmt2993 <div id="rfc.figure.u.63"></div><pre class="text"> example-list = 1#example-list-elmt 3032 2994 example-list-elmt = token ; see <a href="#field.components" title="Field value components">Section 3.2.4</a> 3033 2995 </pre><p id="rfc.section.B.p.11">Then these are valid values for example-list (not including the double quotes, which are present for delimitation only):</p> 3034 <div id="rfc.figure.u.6 5"></div><pre class="text"> "foo,bar"2996 <div id="rfc.figure.u.64"></div><pre class="text"> "foo,bar" 3035 2997 "foo ,bar," 3036 2998 "foo , ,bar,charlie " 3037 2999 </pre><p id="rfc.section.B.p.13">But these values would be invalid, as at least one non-empty element is required:</p> 3038 <div id="rfc.figure.u.6 6"></div><pre class="text"> ""3000 <div id="rfc.figure.u.65"></div><pre class="text"> "" 3039 3001 "," 3040 3002 ", ," … … 3042 3004 </p> 3043 3005 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 3044 <div id="rfc.figure.u.6 7"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS3006 <div id="rfc.figure.u.66"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS 3045 3007 3046 3008 <a href="#header.connection" class="smpl">Connection</a> = *( "," OWS ) connection-option *( OWS "," [ OWS … … 3128 3090 <a href="#chunked.encoding" class="smpl">quoted-str-nf</a> = DQUOTE *( qdtext-nf / quoted-pair ) DQUOTE 3129 3091 <a href="#rule.quoted-string" class="smpl">quoted-string</a> = DQUOTE *( qdtext / quoted-pair ) DQUOTE 3130 <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) 3131 3092 3093 <a href="#header.te" class="smpl">rank</a> = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) 3132 3094 <a href="#status.line" class="smpl">reason-phrase</a> = *( HTAB / SP / VCHAR / obs-text ) 3133 3095 <a href="#header.via" class="smpl">received-by</a> = ( uri-host [ ":" port ] ) / pseudonym … … 3144 3106 <a href="#status.line" class="smpl">status-line</a> = HTTP-version SP status-code SP reason-phrase CRLF 3145 3107 3146 <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( transfer-extension [ te-params ] ) 3108 <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( transfer-coding [ t-ranking ] ) 3109 <a href="#header.te" class="smpl">t-ranking</a> = OWS ";" OWS "q=" rank 3147 3110 <a href="#rule.token.separators" class="smpl">tchar</a> = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / 3148 3111 "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA 3149 <a href="#header.te" class="smpl">te-ext</a> = OWS ";" OWS token [ "=" word ]3150 <a href="#header.te" class="smpl">te-params</a> = OWS ";" OWS "q=" qvalue *te-ext3151 3112 <a href="#rule.token.separators" class="smpl">token</a> = 1*tchar 3152 3113 <a href="#chunked.encoding" class="smpl">trailer-part</a> = *( header-field CRLF ) … … 3613 3574 <li><tt>Grammar</tt> 3614 3575 <ul> 3615 <li><tt>absolute-form</tt> <a href="#rfc.iref.g.8 2"><b>5.3</b></a></li>3576 <li><tt>absolute-form</tt> <a href="#rfc.iref.g.81"><b>5.3</b></a></li> 3616 3577 <li><tt>absolute-URI</tt> <a href="#rfc.iref.g.17"><b>2.8</b></a></li> 3617 3578 <li>ALPHA <a href="#rfc.iref.g.1"><b>1.2</b></a></li> 3618 <li><tt>asterisk-form</tt> <a href="#rfc.iref.g.8 4"><b>5.3</b></a></li>3579 <li><tt>asterisk-form</tt> <a href="#rfc.iref.g.83"><b>5.3</b></a></li> 3619 3580 <li><tt>attribute</tt> <a href="#rfc.iref.g.58"><b>4</b></a></li> 3620 3581 <li><tt>authority</tt> <a href="#rfc.iref.g.18"><b>2.8</b></a></li> 3621 <li><tt>authority-form</tt> <a href="#rfc.iref.g.8 3"><b>5.3</b></a></li>3582 <li><tt>authority-form</tt> <a href="#rfc.iref.g.82"><b>5.3</b></a></li> 3622 3583 <li><tt>BWS</tt> <a href="#rfc.iref.g.40"><b>3.2.1</b></a></li> 3623 3584 <li><tt>chunk</tt> <a href="#rfc.iref.g.63"><b>4.1</b></a></li> … … 3629 3590 <li><tt>chunked-body</tt> <a href="#rfc.iref.g.62"><b>4.1</b></a></li> 3630 3591 <li><tt>comment</tt> <a href="#rfc.iref.g.49"><b>3.2.4</b></a></li> 3631 <li><tt>Connection</tt> <a href="#rfc.iref.g.8 6"><b>6.1</b></a></li>3632 <li><tt>connection-option</tt> <a href="#rfc.iref.g.8 7"><b>6.1</b></a></li>3592 <li><tt>Connection</tt> <a href="#rfc.iref.g.85"><b>6.1</b></a></li> 3593 <li><tt>connection-option</tt> <a href="#rfc.iref.g.86"><b>6.1</b></a></li> 3633 3594 <li><tt>Content-Length</tt> <a href="#rfc.iref.g.54"><b>3.3.2</b></a></li> 3634 3595 <li>CR <a href="#rfc.iref.g.2"><b>1.2</b></a></li> … … 3645 3606 <li><tt>header-field</tt> <a href="#rfc.iref.g.33"><b>3.2</b></a></li> 3646 3607 <li>HEXDIG <a href="#rfc.iref.g.7"><b>1.2</b></a></li> 3647 <li><tt>Host</tt> <a href="#rfc.iref.g.8 5"><b>5.4</b></a></li>3608 <li><tt>Host</tt> <a href="#rfc.iref.g.84"><b>5.4</b></a></li> 3648 3609 <li>HTAB <a href="#rfc.iref.g.8"><b>1.2</b></a></li> 3649 3610 <li><tt>HTTP-message</tt> <a href="#rfc.iref.g.26"><b>3</b></a></li> … … 3659 3620 <li><tt>obs-text</tt> <a href="#rfc.iref.g.47"><b>3.2.4</b></a></li> 3660 3621 <li>OCTET <a href="#rfc.iref.g.10"><b>1.2</b></a></li> 3661 <li><tt>origin-form</tt> <a href="#rfc.iref.g.8 1"><b>5.3</b></a></li>3622 <li><tt>origin-form</tt> <a href="#rfc.iref.g.80"><b>5.3</b></a></li> 3662 3623 <li><tt>OWS</tt> <a href="#rfc.iref.g.38"><b>3.2.1</b></a></li> 3663 3624 <li><tt>partial-URI</tt> <a href="#rfc.iref.g.23"><b>2.8</b></a></li> 3664 3625 <li><tt>path-absolute</tt> <a href="#rfc.iref.g.19"><b>2.8</b></a></li> 3665 3626 <li><tt>port</tt> <a href="#rfc.iref.g.20"><b>2.8</b></a></li> 3666 <li><tt>protocol-name</tt> <a href="#rfc.iref.g. 90"><b>6.2</b></a></li>3667 <li><tt>protocol-version</tt> <a href="#rfc.iref.g.9 1"><b>6.2</b></a></li>3668 <li><tt>pseudonym</tt> <a href="#rfc.iref.g.9 3"><b>6.2</b></a></li>3627 <li><tt>protocol-name</tt> <a href="#rfc.iref.g.89"><b>6.2</b></a></li> 3628 <li><tt>protocol-version</tt> <a href="#rfc.iref.g.90"><b>6.2</b></a></li> 3629 <li><tt>pseudonym</tt> <a href="#rfc.iref.g.92"><b>6.2</b></a></li> 3669 3630 <li><tt>qdtext</tt> <a href="#rfc.iref.g.46"><b>3.2.4</b></a></li> 3670 3631 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.72"><b>4.1</b></a></li> … … 3674 3635 <li><tt>quoted-str-nf</tt> <a href="#rfc.iref.g.71"><b>4.1</b></a></li> 3675 3636 <li><tt>quoted-string</tt> <a href="#rfc.iref.g.45"><b>3.2.4</b></a></li> 3676 <li><tt> qvalue</tt> <a href="#rfc.iref.g.78"><b>4.3.1</b></a></li>3637 <li><tt>rank</tt> <a href="#rfc.iref.g.77"><b>4.3</b></a></li> 3677 3638 <li><tt>reason-phrase</tt> <a href="#rfc.iref.g.32"><b>3.1.2</b></a></li> 3678 <li><tt>received-by</tt> <a href="#rfc.iref.g.9 2"><b>6.2</b></a></li>3679 <li><tt>received-protocol</tt> <a href="#rfc.iref.g.8 9"><b>6.2</b></a></li>3639 <li><tt>received-by</tt> <a href="#rfc.iref.g.91"><b>6.2</b></a></li> 3640 <li><tt>received-protocol</tt> <a href="#rfc.iref.g.88"><b>6.2</b></a></li> 3680 3641 <li><tt>request-line</tt> <a href="#rfc.iref.g.28"><b>3.1.1</b></a></li> 3681 <li><tt>request-target</tt> <a href="#rfc.iref.g. 80"><b>5.3</b></a></li>3642 <li><tt>request-target</tt> <a href="#rfc.iref.g.79"><b>5.3</b></a></li> 3682 3643 <li><tt>RWS</tt> <a href="#rfc.iref.g.39"><b>3.2.1</b></a></li> 3683 3644 <li>SP <a href="#rfc.iref.g.11"><b>1.2</b></a></li> … … 3687 3648 <li><tt>status-line</tt> <a href="#rfc.iref.g.30"><b>3.1.2</b></a></li> 3688 3649 <li><tt>t-codings</tt> <a href="#rfc.iref.g.75"><b>4.3</b></a></li> 3650 <li><tt>t-ranking</tt> <a href="#rfc.iref.g.76"><b>4.3</b></a></li> 3689 3651 <li><tt>tchar</tt> <a href="#rfc.iref.g.43"><b>3.2.4</b></a></li> 3690 3652 <li><tt>TE</tt> <a href="#rfc.iref.g.74"><b>4.3</b></a></li> 3691 <li><tt>te-ext</tt> <a href="#rfc.iref.g.77"><b>4.3</b></a></li>3692 <li><tt>te-params</tt> <a href="#rfc.iref.g.76"><b>4.3</b></a></li>3693 3653 <li><tt>token</tt> <a href="#rfc.iref.g.42"><b>3.2.4</b></a></li> 3694 <li><tt>Trailer</tt> <a href="#rfc.iref.g.7 9"><b>4.4</b></a></li>3654 <li><tt>Trailer</tt> <a href="#rfc.iref.g.78"><b>4.4</b></a></li> 3695 3655 <li><tt>trailer-part</tt> <a href="#rfc.iref.g.70"><b>4.1</b></a></li> 3696 3656 <li><tt>transfer-coding</tt> <a href="#rfc.iref.g.55"><b>4</b></a></li> … … 3698 3658 <li><tt>transfer-extension</tt> <a href="#rfc.iref.g.56"><b>4</b></a></li> 3699 3659 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.57"><b>4</b></a></li> 3700 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.9 4"><b>6.5</b></a></li>3660 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.93"><b>6.5</b></a></li> 3701 3661 <li><tt>uri-host</tt> <a href="#rfc.iref.g.22"><b>2.8</b></a></li> 3702 3662 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.16"><b>2.8</b></a></li> 3703 3663 <li><tt>value</tt> <a href="#rfc.iref.g.59"><b>4</b></a></li> 3704 3664 <li>VCHAR <a href="#rfc.iref.g.12"><b>1.2</b></a></li> 3705 <li><tt>Via</tt> <a href="#rfc.iref.g.8 8"><b>6.2</b></a></li>3665 <li><tt>Via</tt> <a href="#rfc.iref.g.87"><b>6.2</b></a></li> 3706 3666 <li><tt>word</tt> <a href="#rfc.iref.g.41"><b>3.2.4</b></a></li> 3707 3667 </ul> … … 3717 3677 <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> 3718 3678 <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> 3719 <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"> 4.3.1</a>, <a href="#rfc.xref.header.te.4">7.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> 3720 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> 3721 3681 <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> … … 3767 3727 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3768 3728 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6.3.1</a>, <a href="#Pad1995"><b>10.2</b></a></li> 3769 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.4</a>, <a href="#rfc.xref.Part2.4">2.8.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3 .1</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5.6.2</a>, <a href="#rfc.xref.Part2.16">5.6.2</a>, <a href="#rfc.xref.Part2.17">5.6.2</a>, <a href="#rfc.xref.Part2.18">5.6.2</a>, <a href="#rfc.xref.Part2.19">5.6.2</a>, <a href="#rfc.xref.Part2.20">5.6.2</a>, <a href="#rfc.xref.Part2.21">5.7</a>, <a href="#rfc.xref.Part2.22">6.3.2.2</a>, <a href="#rfc.xref.Part2.23">6.3.4</a>, <a href="#rfc.xref.Part2.24">6.4.3</a>, <a href="#rfc.xref.Part2.25">6.4.3</a>, <a href="#rfc.xref.Part2.26">6.4.3</a>, <a href="#rfc.xref.Part2.27">6.5</a>, <a href="#rfc.xref.Part2.28">7.4</a>, <a href="#rfc.xref.Part2.29">8.6</a>, <a href="#rfc.xref.Part2.30">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>3729 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.4</a>, <a href="#rfc.xref.Part2.4">2.8.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5.6.2</a>, <a href="#rfc.xref.Part2.16">5.6.2</a>, <a href="#rfc.xref.Part2.17">5.6.2</a>, <a href="#rfc.xref.Part2.18">5.6.2</a>, <a href="#rfc.xref.Part2.19">5.6.2</a>, <a href="#rfc.xref.Part2.20">5.6.2</a>, <a href="#rfc.xref.Part2.21">5.7</a>, <a href="#rfc.xref.Part2.22">6.3.2.2</a>, <a href="#rfc.xref.Part2.23">6.3.4</a>, <a href="#rfc.xref.Part2.24">6.4.3</a>, <a href="#rfc.xref.Part2.25">6.4.3</a>, <a href="#rfc.xref.Part2.26">6.4.3</a>, <a href="#rfc.xref.Part2.27">6.5</a>, <a href="#rfc.xref.Part2.28">7.4</a>, <a href="#rfc.xref.Part2.29">8.6</a>, <a href="#rfc.xref.Part2.30">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul> 3770 3730 <li><em>Section 2</em> <a href="#rfc.xref.Part2.5">3.1.1</a></li> 3771 3731 <li><em>Section 2.1.2</em> <a href="#rfc.xref.Part2.22">6.3.2.2</a>, <a href="#rfc.xref.Part2.23">6.3.4</a></li> … … 3781 3741 <li><em>Section 4.6.12</em> <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.29">8.6</a></li> 3782 3742 <li><em>Section 5.4</em> <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.28">7.4</a></li> 3783 <li><em>Section 8 </em> <a href="#rfc.xref.Part2.11">4.3.1</a></li>3743 <li><em>Section 8.3</em> <a href="#rfc.xref.Part2.11">4.3</a></li> 3784 3744 <li><em>Section 9.5</em> <a href="#rfc.xref.Part2.15">5.6.2</a></li> 3785 3745 <li><em>Section 9.6</em> <a href="#rfc.xref.Part2.18">5.6.2</a></li> … … 3899 3859 <li>target resource <a href="#rfc.iref.t.7"><b>5.1</b></a></li> 3900 3860 <li>target URI <a href="#rfc.iref.t.8"><b>5.1</b></a></li> 3901 <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"> 4.3.1</a>, <a href="#rfc.xref.header.te.4">7.1</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> 3902 3862 <li><em>Tou1998</em> <a href="#rfc.xref.Tou1998.1">6.3.1</a>, <a href="#Tou1998"><b>10.2</b></a></li> 3903 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>
Note: See TracChangeset
for help on using the changeset viewer.