![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 1584 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 12/03/12 05:00:28 (11 years ago)
- File:
-
- 1 edited
-
draft-ietf-httpbis/latest/p1-messaging.html (modified) (33 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1583 r1584 696 696 </ul> 697 697 </li> 698 <li>4.3 <a href="#transfer.coding.registry">Transfer Coding Registry</a></li> 699 <li>4.4 <a href="#header.te">TE</a><ul> 700 <li>4.4.1 <a href="#quality.values">Quality Values</a></li> 698 <li>4.3 <a href="#header.te">TE</a><ul> 699 <li>4.3.1 <a href="#quality.values">Quality Values</a></li> 701 700 </ul> 702 701 </li> 703 <li>4. 5 <a href="#header.trailer">Trailer</a></li>702 <li>4.4 <a href="#header.trailer">Trailer</a></li> 704 703 </ul> 705 704 </li> … … 739 738 </ul> 740 739 </li> 741 <li>6.5 <a href="#header.upgrade">Upgrade</a><ul> 742 <li>6.5.1 <a href="#upgrade.token.registry">Upgrade Token Registry</a></li> 743 </ul> 744 </li> 740 <li>6.5 <a href="#header.upgrade">Upgrade</a></li> 745 741 </ul> 746 742 </li> … … 753 749 </ul> 754 750 </li> 755 <li>7.4 <a href="#transfer.coding.registration">Transfer Coding Registry</a></li> 756 <li>7.5 <a href="#upgrade.token.registration">Upgrade Token Registration</a></li> 751 <li>7.4 <a href="#transfer.coding.registry">Transfer Coding Registry</a></li> 752 <li>7.5 <a href="#transfer.coding.registration">Transfer Coding Registrations</a></li> 753 <li>7.6 <a href="#upgrade.token.registry">Upgrade Token Registry</a></li> 754 <li>7.7 <a href="#upgrade.token.registration">Upgrade Token Registration</a></li> 757 755 </ul> 758 756 </li> … … 1632 1630 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#rule.token.separators" class="smpl">token</a> 1633 1631 <a href="#rule.parameter" class="smpl">value</a> = <a href="#rule.token.separators" class="smpl">word</a> 1634 </pre><p id="rfc.section.4.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section 4.4</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 3.3.1</a>).1632 </pre><p id="rfc.section.4.p.5">All transfer-coding values are case-insensitive. The HTTP Transfer Coding registry is defined in <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 7.4</a>. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section 4.3</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 3.3.1</a>). 1635 1633 </p> 1636 1634 <div id="rfc.iref.c.7"></div> … … 1664 1662 </p> 1665 1663 <p id="rfc.section.4.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field 1666 can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section 4. 5</a>).1664 can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section 4.4</a>). 1667 1665 </p> 1668 1666 <p id="rfc.section.4.1.p.5">A server using chunked transfer-coding in a response <em class="bcp14">MUST NOT</em> use the trailer for any header fields unless at least one of the following is true: … … 1670 1668 <ol> 1671 1669 <li>the request included a TE header field that indicates "trailers" is acceptable in the transfer-coding of the response, as 1672 described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section 4. 4</a>; or,1670 described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section 4.3</a>; or, 1673 1671 </li> 1674 1672 <li>the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable … … 1733 1731 <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. 1734 1732 </p> 1735 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="transfer.coding.registry" href="#transfer.coding.registry">Transfer Coding Registry</a></h2>1736 <p id="rfc.section.4.3.p.1">The HTTP Transfer Coding Registry defines the name space for the transfer coding names.</p>1737 <p id="rfc.section.4.3.p.2">Registrations <em class="bcp14">MUST</em> include the following fields:1738 </p>1739 <ul>1740 <li>Name</li>1741 <li>Description</li>1742 <li>Pointer to specification text</li>1743 </ul>1744 <p id="rfc.section.4.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</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>).1745 </p>1746 <p id="rfc.section.4.3.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.1747 </p>1748 <p id="rfc.section.4.3.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>>.1749 </p>1750 1733 <div id="rfc.iref.t.5"></div> 1751 1734 <div id="rfc.iref.h.8"></div> 1752 <h2 id="rfc.section.4. 4"><a href="#rfc.section.4.4">4.4</a> <a id="header.te" href="#header.te">TE</a></h2>1753 <p id="rfc.section.4. 4.p.1">The "TE" header field indicates what extension transfer-codings the client is willing to accept in the response, and whether1735 <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> 1736 <p id="rfc.section.4.3.p.1">The "TE" header field indicates what extension transfer-codings the client is willing to accept in the response, and whether 1754 1737 or not it is willing to accept trailer fields in a chunked transfer-coding. 1755 1738 </p> 1756 <p id="rfc.section.4. 4.p.2">Its value consists of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional1739 <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 optional 1757 1740 accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 4</a>). 1758 1741 </p> … … 1761 1744 <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> ) 1762 1745 <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> ] 1763 </pre><p id="rfc.section.4. 4.p.4">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding,1746 </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, 1764 1747 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. 1765 1748 </p> 1766 <p id="rfc.section.4. 4.p.5">Examples of its use are:</p>1749 <p id="rfc.section.4.3.p.5">Examples of its use are:</p> 1767 1750 <div id="rfc.figure.u.42"></div><pre class="text"> TE: deflate 1768 1751 TE: 1769 1752 TE: trailers, deflate;q=0.5 1770 </pre><p id="rfc.section.4. 4.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection 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.1771 </p> 1772 <p id="rfc.section.4. 4.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p>1753 </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 Connection 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. 1754 </p> 1755 <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> 1773 1756 <ol> 1774 1757 <li> … … 1784 1767 <li> 1785 1768 <p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it 1786 is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section 4. 4.1</a>, a qvalue of 0 means "not acceptable".)1769 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".) 1787 1770 </p> 1788 1771 </li> … … 1793 1776 </li> 1794 1777 </ol> 1795 <p id="rfc.section.4. 4.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 with1778 <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 1796 1779 no transfer-coding is always acceptable. 1797 1780 </p> 1798 <h3 id="rfc.section.4. 4.1"><a href="#rfc.section.4.4.1">4.4.1</a> <a id="quality.values" href="#quality.values">Quality Values</a></h3>1799 <p id="rfc.section.4. 4.1.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 4.4</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight1781 <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> 1782 <p id="rfc.section.4.3.1.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 4.3</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight 1800 1783 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 1801 1784 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. … … 1803 1786 <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.77"></span> <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] ) 1804 1787 / ( "1" [ "." 0*3("0") ] ) 1805 </pre><div class="note" id="rfc.section.4. 4.1.p.3">1788 </pre><div class="note" id="rfc.section.4.3.1.p.3"> 1806 1789 <p> <b>Note:</b> "Quality values" is a misnomer, since these values merely represent relative degradation in desired quality. 1807 1790 </p> … … 1809 1792 <div id="rfc.iref.t.6"></div> 1810 1793 <div id="rfc.iref.h.9"></div> 1811 <h2 id="rfc.section.4. 5"><a href="#rfc.section.4.5">4.5</a> <a id="header.trailer" href="#header.trailer">Trailer</a></h2>1812 <p id="rfc.section.4. 5.p.1">The "Trailer" header field indicates that the given set of header fields is present in the trailer of a message encoded with1794 <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="header.trailer" href="#header.trailer">Trailer</a></h2> 1795 <p id="rfc.section.4.4.p.1">The "Trailer" header field indicates that the given set of header fields is present in the trailer of a message encoded with 1813 1796 chunked transfer-coding. 1814 1797 </p> 1815 1798 <div id="rfc.figure.u.44"></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> 1816 </pre><p id="rfc.section.4. 5.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 recipient1799 </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 1817 1800 to know which header fields to expect in the trailer. 1818 1801 </p> 1819 <p id="rfc.section.4. 5.p.4">If no Trailer header field is present, the trailer <em class="bcp14">SHOULD NOT</em> include any header fields. See <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding.1820 </p> 1821 <p id="rfc.section.4. 5.p.5">Message header fields listed in the Trailer header field <em class="bcp14">MUST NOT</em> include the following header fields:1802 <p id="rfc.section.4.4.p.4">If no Trailer header field is present, the trailer <em class="bcp14">SHOULD NOT</em> include any header fields. See <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding. 1803 </p> 1804 <p id="rfc.section.4.4.p.5">Message header fields listed in the Trailer header field <em class="bcp14">MUST NOT</em> include the following header fields: 1822 1805 </p> 1823 1806 <ul> … … 2057 2040 </p> 2058 2041 </div> 2059 <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3. 5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 4</a>).2042 <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 4</a>). 2060 2043 </p> 2061 2044 <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a> <a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2> … … 2348 2331 <p id="rfc.section.6.5.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined 2349 2332 by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section 2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined 2350 below. 2351 </p> 2352 <h3 id="rfc.section.6.5.1"><a href="#rfc.section.6.5.1">6.5.1</a> <a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h3> 2353 <p id="rfc.section.6.5.1.p.1">The HTTP Upgrade Token Registry defines the name space for protocol-name tokens used to identify protocols in the Upgrade 2354 header field. Each registered protocol-name is associated with contact information and an optional set of specifications that 2355 details how the connection will be processed after it has been upgraded. 2356 </p> 2357 <p id="rfc.section.6.5.1.p.2">Registrations 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.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>) and are subject to the following rules: 2358 </p> 2359 <ol> 2360 <li>A protocol-name token, once registered, stays registered forever.</li> 2361 <li>The registration <em class="bcp14">MUST</em> name a responsible party for the registration. 2362 </li> 2363 <li>The registration <em class="bcp14">MUST</em> name a point of contact. 2364 </li> 2365 <li>The registration <em class="bcp14">MAY</em> name a set of specifications associated with that token. Such specifications need not be publicly available. 2366 </li> 2367 <li>The registration <em class="bcp14">SHOULD</em> name a set of expected "protocol-version" tokens associated with that token at the time of registration. 2368 </li> 2369 <li>The responsible party <em class="bcp14">MAY</em> change the registration at any time. The IANA will keep a record of all such changes, and make them available upon request. 2370 </li> 2371 <li>The IESG <em class="bcp14">MAY</em> reassign responsibility for a protocol token. This will normally only be used in the case when a responsible party cannot 2372 be contacted. 2373 </li> 2374 </ol> 2333 in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 7.6</a>. 2334 </p> 2375 2335 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 2376 2336 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 2377 <p id="rfc.section.7.1.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>): 2337 <p id="rfc.section.7.1.p.1">HTTP header fields are registered within the Message Header Field Registry <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a> maintained by IANA at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>>. 2338 </p> 2339 <p id="rfc.section.7.1.p.2">This document defines the following HTTP header fields, so their associated registry entries shall be updated according to 2340 the permanent registrations below: 2378 2341 </p> 2379 2342 <div id="rfc.table.1"> … … 2414 2377 <td class="left">http</td> 2415 2378 <td class="left">standard</td> 2416 <td class="left"> <a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section 4. 4</a>2379 <td class="left"> <a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section 4.3</a> 2417 2380 </td> 2418 2381 </tr> … … 2421 2384 <td class="left">http</td> 2422 2385 <td class="left">standard</td> 2423 <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section 4. 5</a>2386 <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section 4.4</a> 2424 2387 </td> 2425 2388 </tr> … … 2448 2411 </table> 2449 2412 </div> 2450 <p id="rfc.section.7.1.p. 2">Furthermore, the header field name "Close" shall be registered as "reserved", as its use as HTTP header field would be in2451 conflict with the use of the "close" connection option forthe "Connection" header field (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section 6.1</a>).2413 <p id="rfc.section.7.1.p.3">Furthermore, the header field-name "Close" shall be registered as "reserved", since using that name as an HTTP header field 2414 might conflict with the "close" connection option of the "Connection" header field (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section 6.1</a>). 2452 2415 </p> 2453 2416 <div id="rfc.table.u.1"> … … 2472 2435 </table> 2473 2436 </div> 2474 <p id="rfc.section.7.1.p. 3">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>2437 <p id="rfc.section.7.1.p.4">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 2475 2438 <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="uri.scheme.registration" href="#uri.scheme.registration">URI Scheme Registration</a></h2> 2476 <p id="rfc.section.7.2.p.1">The entries for the "http" and "https" URI Schemes in the registry located at <<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>> shall be updated to point to Sections <a href="#http.uri" title="http URI scheme">2.7.1</a> and <a href="#https.uri" title="https URI scheme">2.7.2</a> of this document (see <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a>). 2477 </p> 2439 <p id="rfc.section.7.2.p.1">IANA maintains the registry of URI Schemes <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a> at <<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>>. 2440 </p> 2441 <p id="rfc.section.7.2.p.2">This document defines the following URI schemes, so their associated registry entries shall be updated according to the permanent 2442 registrations below: 2443 </p> 2444 <div id="rfc.table.u.2"> 2445 <table class="tt full left" cellpadding="3" cellspacing="0"> 2446 <thead> 2447 <tr> 2448 <th>URI Scheme</th> 2449 <th>Description</th> 2450 <th>Reference</th> 2451 </tr> 2452 </thead> 2453 <tbody> 2454 <tr> 2455 <td class="left">http</td> 2456 <td class="left">Hypertext Transfer Protocol</td> 2457 <td class="left"><a href="#http.uri" title="http URI scheme">Section 2.7.1</a></td> 2458 </tr> 2459 <tr> 2460 <td class="left">https</td> 2461 <td class="left">Hypertext Transfer Protocol Secure</td> 2462 <td class="left"><a href="#https.uri" title="https URI scheme">Section 2.7.2</a></td> 2463 </tr> 2464 </tbody> 2465 </table> 2466 </div> 2478 2467 <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Type Registrations</a></h2> 2479 2468 <p id="rfc.section.7.3.p.1">This document serves as the specification for the Internet media types "message/http" and "application/http". The following … … 2590 2579 <dd>IESG</dd> 2591 2580 </dl> 2592 <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a> <a id="transfer.coding.registration" href="#transfer.coding.registration">Transfer Coding Registry</a></h2> 2593 <p id="rfc.section.7.4.p.1">The registration procedure for HTTP Transfer Codings is now defined by <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 4.3</a> of this document. 2594 </p> 2595 <p id="rfc.section.7.4.p.2">The HTTP Transfer Codings Registry located at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>> shall be updated with the registrations below: 2596 </p> 2581 <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a> <a id="transfer.coding.registry" href="#transfer.coding.registry">Transfer Coding Registry</a></h2> 2582 <p id="rfc.section.7.4.p.1">The HTTP Transfer Coding Registry defines the name space for transfer coding names.</p> 2583 <p id="rfc.section.7.4.p.2">Registrations <em class="bcp14">MUST</em> include the following fields: 2584 </p> 2585 <ul> 2586 <li>Name</li> 2587 <li>Description</li> 2588 <li>Pointer to specification text</li> 2589 </ul> 2590 <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="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</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>. 2591 </p> 2592 <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. 2593 </p> 2594 <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>>. 2595 </p> 2596 <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a> <a id="transfer.coding.registration" href="#transfer.coding.registration">Transfer Coding Registrations</a></h2> 2597 <p id="rfc.section.7.5.p.1">The HTTP Transfer Coding Registry shall be updated with the registrations below:</p> 2597 2598 <div id="rfc.table.2"> 2598 2599 <div id="iana.transfer.coding.registration.table"></div> … … 2634 2635 </table> 2635 2636 </div> 2636 <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a> <a id="upgrade.token.registration" href="#upgrade.token.registration">Upgrade Token Registration</a></h2> 2637 <p id="rfc.section.7.5.p.1">The registration procedure for HTTP Upgrade Tokens — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 6.5.1</a> of this document. 2638 </p> 2639 <p id="rfc.section.7.5.p.2">The HTTP Upgrade Token Registry located at <<a href="http://www.iana.org/assignments/http-upgrade-tokens/">http://www.iana.org/assignments/http-upgrade-tokens/</a>> shall be updated with the registration below: 2640 </p> 2641 <div id="rfc.table.u.2"> 2637 <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a> <a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h2> 2638 <p id="rfc.section.7.6.p.1">The HTTP Upgrade Token Registry defines the name space for protocol-name tokens used to identify protocols in the Upgrade 2639 header field. Each registered protocol-name is associated with contact information and an optional set of specifications that 2640 details how the connection will be processed after it has been upgraded. 2641 </p> 2642 <p id="rfc.section.7.6.p.2">Registrations 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.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>) and are subject to the following rules: 2643 </p> 2644 <ol> 2645 <li>A protocol-name token, once registered, stays registered forever.</li> 2646 <li>The registration <em class="bcp14">MUST</em> name a responsible party for the registration. 2647 </li> 2648 <li>The registration <em class="bcp14">MUST</em> name a point of contact. 2649 </li> 2650 <li>The registration <em class="bcp14">MAY</em> name a set of specifications associated with that token. Such specifications need not be publicly available. 2651 </li> 2652 <li>The registration <em class="bcp14">SHOULD</em> name a set of expected "protocol-version" tokens associated with that token at the time of registration. 2653 </li> 2654 <li>The responsible party <em class="bcp14">MAY</em> change the registration at any time. The IANA will keep a record of all such changes, and make them available upon request. 2655 </li> 2656 <li>The IESG <em class="bcp14">MAY</em> reassign responsibility for a protocol token. This will normally only be used in the case when a responsible party cannot 2657 be contacted. 2658 </li> 2659 </ol> 2660 <p id="rfc.section.7.6.p.3">This registration procedure for HTTP Upgrade Tokens replaces that previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. 2661 </p> 2662 <h2 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a> <a id="upgrade.token.registration" href="#upgrade.token.registration">Upgrade Token Registration</a></h2> 2663 <p id="rfc.section.7.7.p.1">The HTTP Upgrade Token Registry shall be updated with the registration below:</p> 2664 <div id="rfc.table.u.3"> 2642 2665 <table class="tt full left" cellpadding="3" cellspacing="0"> 2643 2666 <thead> … … 2645 2668 <th>Value</th> 2646 2669 <th>Description</th> 2670 <th>Expected Version Tokens</th> 2647 2671 <th>Reference</th> 2648 2672 </tr> … … 2652 2676 <td class="left">HTTP</td> 2653 2677 <td class="left">Hypertext Transfer Protocol</td> 2654 <td class="left"> <a href="#http.version" title="Protocol Versioning">Section 2.6</a> of this specification2655 < /td>2678 <td class="left">any DIGIT.DIGIT (e.g, "2.0")</td> 2679 <td class="left"><a href="#http.version" title="Protocol Versioning">Section 2.6</a></td> 2656 2680 </tr> 2657 2681 </tbody> 2658 2682 </table> 2659 2683 </div> 2684 <p id="rfc.section.7.7.p.2">The responsible party is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 2660 2685 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 2661 2686 <p id="rfc.section.8.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1 … … 3038 3063 disallowed line folding in chunk extensions, and deprecate their use. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>) 3039 3064 </p> 3040 <p id="rfc.section.A.2.p.10">Registration of Transfer Codings now requires IETF Review (<a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 4.3</a>)3065 <p id="rfc.section.A.2.p.10">Registration of Transfer Codings now requires IETF Review (<a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 7.4</a>) 3041 3066 </p> 3042 3067 <p id="rfc.section.A.2.p.11">Remove hard limit of two connections per server. Remove requirement to retry a sequence of requests as long it was idempotent. … … 3051 3076 </p> 3052 3077 <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a> <a id="changes.from.rfc.2817" href="#changes.from.rfc.2817">Changes from RFC 2817</a></h2> 3053 <p id="rfc.section.A.3.p.1">Registration of Upgrade tokens now requires IETF Review (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 6.5.1</a>)3078 <p id="rfc.section.A.3.p.1">Registration of Upgrade tokens now requires IETF Review (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 7.6</a>) 3054 3079 </p> 3055 3080 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 3608 3633 <li>compress (Coding Format) <a href="#rfc.iref.c.9">4.2.1</a></li> 3609 3634 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3610 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4. 4</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.xref.header.connection.6">5.6.1</a>, <a href="#rfc.iref.c.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.7">6.3.2</a>, <a href="#rfc.xref.header.connection.8">6.5</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">7.1</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>3635 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.xref.header.connection.6">5.6.1</a>, <a href="#rfc.iref.c.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.7">6.3.2</a>, <a href="#rfc.xref.header.connection.8">6.5</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">7.1</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li> 3611 3636 <li>Content-Length header field <a href="#rfc.iref.c.6"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">3.3.2</a>, <a href="#rfc.xref.header.content-length.2">7.1</a></li> 3612 3637 </ul> … … 3685 3710 <li><tt>quoted-str-nf</tt> <a href="#rfc.iref.g.70"><b>4.1</b></a></li> 3686 3711 <li><tt>quoted-string</tt> <a href="#rfc.iref.g.44"><b>3.2.4</b></a></li> 3687 <li><tt>qvalue</tt> <a href="#rfc.iref.g.77"><b>4. 4.1</b></a></li>3712 <li><tt>qvalue</tt> <a href="#rfc.iref.g.77"><b>4.3.1</b></a></li> 3688 3713 <li><tt>reason-phrase</tt> <a href="#rfc.iref.g.31"><b>3.1.2</b></a></li> 3689 3714 <li><tt>received-by</tt> <a href="#rfc.iref.g.91"><b>6.2</b></a></li> … … 3697 3722 <li><tt>status-code</tt> <a href="#rfc.iref.g.30"><b>3.1.2</b></a></li> 3698 3723 <li><tt>status-line</tt> <a href="#rfc.iref.g.29"><b>3.1.2</b></a></li> 3699 <li><tt>t-codings</tt> <a href="#rfc.iref.g.74"><b>4. 4</b></a></li>3724 <li><tt>t-codings</tt> <a href="#rfc.iref.g.74"><b>4.3</b></a></li> 3700 3725 <li><tt>tchar</tt> <a href="#rfc.iref.g.42"><b>3.2.4</b></a></li> 3701 <li><tt>TE</tt> <a href="#rfc.iref.g.73"><b>4. 4</b></a></li>3702 <li><tt>te-ext</tt> <a href="#rfc.iref.g.76"><b>4. 4</b></a></li>3703 <li><tt>te-params</tt> <a href="#rfc.iref.g.75"><b>4. 4</b></a></li>3726 <li><tt>TE</tt> <a href="#rfc.iref.g.73"><b>4.3</b></a></li> 3727 <li><tt>te-ext</tt> <a href="#rfc.iref.g.76"><b>4.3</b></a></li> 3728 <li><tt>te-params</tt> <a href="#rfc.iref.g.75"><b>4.3</b></a></li> 3704 3729 <li><tt>token</tt> <a href="#rfc.iref.g.41"><b>3.2.4</b></a></li> 3705 <li><tt>Trailer</tt> <a href="#rfc.iref.g.78"><b>4. 5</b></a></li>3730 <li><tt>Trailer</tt> <a href="#rfc.iref.g.78"><b>4.4</b></a></li> 3706 3731 <li><tt>trailer-part</tt> <a href="#rfc.iref.g.69"><b>4.1</b></a></li> 3707 3732 <li><tt>transfer-coding</tt> <a href="#rfc.iref.g.54"><b>4</b></a></li> … … 3725 3750 <li>Header Fields 3726 3751 <ul> 3727 <li>Connection <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4. 4</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.xref.header.connection.6">5.6.1</a>, <a href="#rfc.iref.h.12"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.7">6.3.2</a>, <a href="#rfc.xref.header.connection.8">6.5</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">7.1</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>3752 <li>Connection <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.xref.header.connection.6">5.6.1</a>, <a href="#rfc.iref.h.12"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.7">6.3.2</a>, <a href="#rfc.xref.header.connection.8">6.5</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">7.1</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li> 3728 3753 <li>Content-Length <a href="#rfc.iref.h.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">3.3.2</a>, <a href="#rfc.xref.header.content-length.2">7.1</a></li> 3729 3754 <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> 3730 <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. 4</b></a>, <a href="#rfc.xref.header.te.3">4.4.1</a>, <a href="#rfc.xref.header.te.4">7.1</a></li>3731 <li>Trailer <a href="#rfc.xref.header.trailer.1">4.1</a>, <a href="#rfc.iref.h.9"><b>4. 5</b></a>, <a href="#rfc.xref.header.trailer.2">7.1</a></li>3755 <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> 3756 <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> 3732 3757 <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></li> 3733 3758 <li>Upgrade <a href="#rfc.iref.h.14"><b>6.5</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li> … … 3795 3820 </ul> 3796 3821 </li> 3797 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">3.3.1</a>, <a href="#rfc.xref.Part3.3">4.3 </a>, <a href="#rfc.xref.Part3.4">4.4.1</a>, <a href="#rfc.xref.Part3.5">5.6.2</a>, <a href="#Part3"><b>10.1</b></a><ul>3798 <li><em>Section 2.2</em> <a href="#rfc.xref.Part3.2">3.3.1</a>, <a href="#rfc.xref.Part3. 3">4.3</a></li>3799 <li><em>Section 5</em> <a href="#rfc.xref.Part3. 4">4.4.1</a></li>3822 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">3.3.1</a>, <a href="#rfc.xref.Part3.3">4.3.1</a>, <a href="#rfc.xref.Part3.4">5.6.2</a>, <a href="#rfc.xref.Part3.5">7.4</a>, <a href="#Part3"><b>10.1</b></a><ul> 3823 <li><em>Section 2.2</em> <a href="#rfc.xref.Part3.2">3.3.1</a>, <a href="#rfc.xref.Part3.5">7.4</a></li> 3824 <li><em>Section 5</em> <a href="#rfc.xref.Part3.3">4.3.1</a></li> 3800 3825 <li><em>Appendix A</em> <a href="#rfc.xref.Part3.1">1</a></li> 3801 3826 </ul> … … 3820 3845 <li><em>RFC1919</em> <a href="#rfc.xref.RFC1919.1">2.3</a>, <a href="#RFC1919"><b>10.2</b></a></li> 3821 3846 <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1">2.6</a>, <a href="#RFC1945"><b>10.2</b></a>, <a href="#rfc.xref.RFC1945.2">A</a></li> 3822 <li><em>RFC1950</em> <a href="#rfc.xref.RFC1950.1">4.2.2</a>, <a href="#rfc.xref.RFC1950.2">7. 4</a>, <a href="#RFC1950"><b>10.1</b></a></li>3823 <li><em>RFC1951</em> <a href="#rfc.xref.RFC1951.1">4.2.2</a>, <a href="#rfc.xref.RFC1951.2">7. 4</a>, <a href="#RFC1951"><b>10.1</b></a></li>3824 <li><em>RFC1952</em> <a href="#rfc.xref.RFC1952.1">4.2.3</a>, <a href="#rfc.xref.RFC1952.2">7. 4</a>, <a href="#RFC1952"><b>10.1</b></a></li>3847 <li><em>RFC1950</em> <a href="#rfc.xref.RFC1950.1">4.2.2</a>, <a href="#rfc.xref.RFC1950.2">7.5</a>, <a href="#RFC1950"><b>10.1</b></a></li> 3848 <li><em>RFC1951</em> <a href="#rfc.xref.RFC1951.1">4.2.2</a>, <a href="#rfc.xref.RFC1951.2">7.5</a>, <a href="#RFC1951"><b>10.1</b></a></li> 3849 <li><em>RFC1952</em> <a href="#rfc.xref.RFC1952.1">4.2.3</a>, <a href="#rfc.xref.RFC1952.2">7.5</a>, <a href="#RFC1952"><b>10.1</b></a></li> 3825 3850 <li><em>RFC2045</em> <a href="#rfc.xref.RFC2045.1">1</a>, <a href="#rfc.xref.RFC2045.2">3.3.1</a>, <a href="#RFC2045"><b>10.2</b></a><ul> 3826 3851 <li><em>Section 6</em> <a href="#rfc.xref.RFC2045.2">3.3.1</a></li> … … 3838 3863 </ul> 3839 3864 </li> 3840 <li><em>RFC2817</em> <a href="#rfc.xref.RFC2817.1">§</a>, <a href="#rfc.xref.RFC2817.2">7. 5</a>, <a href="#RFC2817"><b>10.2</b></a>, <a href="#rfc.xref.RFC2817.3">A.2</a><ul>3841 <li><em>Section 7.2</em> <a href="#rfc.xref.RFC2817.2">7. 5</a></li>3865 <li><em>RFC2817</em> <a href="#rfc.xref.RFC2817.1">§</a>, <a href="#rfc.xref.RFC2817.2">7.6</a>, <a href="#RFC2817"><b>10.2</b></a>, <a href="#rfc.xref.RFC2817.3">A.2</a><ul> 3866 <li><em>Section 7.2</em> <a href="#rfc.xref.RFC2817.2">7.6</a></li> 3842 3867 </ul> 3843 3868 </li> … … 3865 3890 <li><em>RFC4395</em> <a href="#rfc.xref.RFC4395.1">7.2</a>, <a href="#RFC4395"><b>10.2</b></a></li> 3866 3891 <li><em>RFC4559</em> <a href="#rfc.xref.RFC4559.1">2.3</a>, <a href="#RFC4559"><b>10.2</b></a></li> 3867 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1"> 4.3</a>, <a href="#rfc.xref.RFC5226.2">6.5.1</a>, <a href="#RFC5226"><b>10.2</b></a><ul>3868 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1"> 4.3</a>, <a href="#rfc.xref.RFC5226.2">6.5.1</a></li>3892 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">7.4</a>, <a href="#rfc.xref.RFC5226.2">7.6</a>, <a href="#RFC5226"><b>10.2</b></a><ul> 3893 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">7.4</a>, <a href="#rfc.xref.RFC5226.2">7.6</a></li> 3869 3894 </ul> 3870 3895 </li> … … 3890 3915 <li>target resource <a href="#rfc.iref.t.7"><b>5.1</b></a></li> 3891 3916 <li>target URI <a href="#rfc.iref.t.8"><b>5.1</b></a></li> 3892 <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. 4</b></a>, <a href="#rfc.xref.header.te.3">4.4.1</a>, <a href="#rfc.xref.header.te.4">7.1</a></li>3917 <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> 3893 3918 <li><em>Tou1998</em> <a href="#rfc.xref.Tou1998.1">6.3.1</a>, <a href="#Tou1998"><b>10.2</b></a></li> 3894 <li>Trailer header field <a href="#rfc.xref.header.trailer.1">4.1</a>, <a href="#rfc.iref.t.6"><b>4. 5</b></a>, <a href="#rfc.xref.header.trailer.2">7.1</a></li>3919 <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> 3895 3920 <li>Transfer-Encoding header field <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.t.4"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">4</a>, <a href="#rfc.xref.header.transfer-encoding.3">7.1</a></li> 3896 3921 <li>transforming proxy <a href="#rfc.iref.t.1"><b>2.3</b></a></li>
Note: See TracChangeset
for help on using the changeset viewer.
