Changeset 1584 for draft-ietf-httpbis/latest
- Timestamp:
- 12/03/12 05:00:28 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
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> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1583 r1584 1944 1944 </artwork></figure> 1945 1945 <t> 1946 All transfer-coding values are case-insensitive. HTTP/1.1 uses 1947 transfer-coding values in the TE header field (<xref target="header.te"/>) and in 1948 the Transfer-Encoding header field (<xref target="header.transfer-encoding"/>). 1946 All transfer-coding values are case-insensitive. 1947 The HTTP Transfer Coding registry is defined in 1948 <xref target="transfer.coding.registry"/>. 1949 HTTP/1.1 uses transfer-coding values in the TE header field 1950 (<xref target="header.te"/>) and in the Transfer-Encoding header field 1951 (<xref target="header.transfer-encoding"/>). 1949 1952 </t> 1950 1953 … … 2112 2115 </section> 2113 2116 2114 </section>2115 2116 <section title="Transfer Coding Registry" anchor="transfer.coding.registry">2117 <t>2118 The HTTP Transfer Coding Registry defines the name space for the transfer2119 coding names.2120 </t>2121 <t>2122 Registrations &MUST; include the following fields:2123 <list style="symbols">2124 <t>Name</t>2125 <t>Description</t>2126 <t>Pointer to specification text</t>2127 </list>2128 </t>2129 <t>2130 Names of transfer codings &MUST-NOT; overlap with names of content codings2131 (&content-codings;), unless the encoding transformation is identical (as it2132 is the case for the compression codings defined in2133 <xref target="compression.codings"/>).2134 </t>2135 <t>2136 Values to be added to this name space require IETF Review (see2137 <xref target="RFC5226" x:fmt="of" x:sec="4.1"/>), and &MUST;2138 conform to the purpose of transfer coding defined in this section.2139 </t>2140 <t>2141 The registry itself is maintained at2142 <eref target="http://www.iana.org/assignments/http-parameters"/>.2143 </t>2144 2117 </section> 2145 2118 … … 3395 3368 version rules of <xref target="http.version"/> and future updates to this 3396 3369 specification. Additional tokens can be registered with IANA using the 3397 registration procedure defined below. 3398 </t> 3399 3400 <section title="Upgrade Token Registry" anchor="upgrade.token.registry"> 3401 <t> 3402 The HTTP Upgrade Token Registry defines the name space for protocol-name 3403 tokens used to identify protocols in the Upgrade header field. 3404 Each registered protocol-name is associated with contact information and 3405 an optional set of specifications that details how the connection 3406 will be processed after it has been upgraded. 3407 </t> 3408 <t> 3409 Registrations require IETF Review (see 3410 <xref target="RFC5226" x:sec="4.1" x:fmt="of"/>) and are subject to the 3411 following rules: 3412 <list style="numbers"> 3413 <t>A protocol-name token, once registered, stays registered forever.</t> 3414 <t>The registration &MUST; name a responsible party for the 3415 registration.</t> 3416 <t>The registration &MUST; name a point of contact.</t> 3417 <t>The registration &MAY; name a set of specifications associated with 3418 that token. Such specifications need not be publicly available.</t> 3419 <t>The registration &SHOULD; name a set of expected "protocol-version" 3420 tokens associated with that token at the time of registration.</t> 3421 <t>The responsible party &MAY; change the registration at any time. 3422 The IANA will keep a record of all such changes, and make them 3423 available upon request.</t> 3424 <t>The IESG &MAY; reassign responsibility for a protocol token. 3425 This will normally only be used in the case when a 3426 responsible party cannot be contacted.</t> 3427 </list> 3428 </t> 3429 </section> 3370 registration procedure defined in <xref target="upgrade.token.registry"/>. 3371 </t> 3430 3372 </section> 3431 3373 … … 3436 3378 <section title="Header Field Registration" anchor="header.field.registration"> 3437 3379 <t> 3438 The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated 3439 with the permanent registrations below (see <xref target="RFC3864"/>): 3380 HTTP header fields are registered within the Message Header Field Registry 3381 <xref target="RFC3864"/> maintained by IANA at 3382 <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/>. 3383 </t> 3384 <t> 3385 This document defines the following HTTP header fields, so their 3386 associated registry entries shall be updated according to the permanent 3387 registrations below: 3440 3388 </t> 3441 3389 <?BEGININC p1-messaging.iana-headers ?> … … 3499 3447 <?ENDINC p1-messaging.iana-headers ?> 3500 3448 <t> 3501 Furthermore, the header field name "Close" shall be registered as "reserved", as its use as 3502 HTTP header field would be in conflict with the use of the "close" connection 3503 option for the "Connection" header field (<xref target="header.connection"/>). 3449 Furthermore, the header field-name "Close" shall be registered as 3450 "reserved", since using that name as an HTTP header field might 3451 conflict with the "close" connection option of the "Connection" 3452 header field (<xref target="header.connection"/>). 3504 3453 </t> 3505 3454 <texttable align="left" suppress-title="true"> … … 3523 3472 <section title="URI Scheme Registration" anchor="uri.scheme.registration"> 3524 3473 <t> 3525 The entries for the "http" and "https" URI Schemes in the registry located at 3526 <eref target="http://www.iana.org/assignments/uri-schemes.html"/> 3527 shall be updated to point to Sections <xref target="http.uri" format="counter"/> 3528 and <xref target="https.uri" format="counter"/> of this document 3529 (see <xref target="RFC4395"/>). 3530 </t> 3474 IANA maintains the registry of URI Schemes <xref target="RFC4395"/> at 3475 <eref target="http://www.iana.org/assignments/uri-schemes.html"/>. 3476 </t> 3477 <t> 3478 This document defines the following URI schemes, so their 3479 associated registry entries shall be updated according to the permanent 3480 registrations below: 3481 </t> 3482 <texttable align="left" suppress-title="true"> 3483 <ttcol>URI Scheme</ttcol> 3484 <ttcol>Description</ttcol> 3485 <ttcol>Reference</ttcol> 3486 3487 <c>http</c> 3488 <c>Hypertext Transfer Protocol</c> 3489 <c><xref target="http.uri"/></c> 3490 3491 <c>https</c> 3492 <c>Hypertext Transfer Protocol Secure</c> 3493 <c><xref target="https.uri"/></c> 3494 </texttable> 3531 3495 </section> 3532 3496 … … 3681 3645 </section> 3682 3646 3683 <section title="Transfer Coding Registry" anchor="transfer.coding.registration"> 3684 <t> 3685 The registration procedure for HTTP Transfer Codings is now defined by 3686 <xref target="transfer.coding.registry"/> of this document. 3687 </t> 3688 <t> 3689 The HTTP Transfer Codings Registry located at <eref target="http://www.iana.org/assignments/http-parameters"/> 3690 shall be updated with the registrations below: 3647 <section title="Transfer Coding Registry" anchor="transfer.coding.registry"> 3648 <t> 3649 The HTTP Transfer Coding Registry defines the name space for transfer 3650 coding names. 3651 </t> 3652 <t> 3653 Registrations &MUST; include the following fields: 3654 <list style="symbols"> 3655 <t>Name</t> 3656 <t>Description</t> 3657 <t>Pointer to specification text</t> 3658 </list> 3659 </t> 3660 <t> 3661 Names of transfer codings &MUST-NOT; overlap with names of content codings 3662 (&content-codings;) unless the encoding transformation is identical, as it 3663 is the case for the compression codings defined in 3664 <xref target="compression.codings"/>. 3665 </t> 3666 <t> 3667 Values to be added to this name space require IETF Review (see 3668 <xref target="RFC5226" x:fmt="of" x:sec="4.1"/>), and &MUST; 3669 conform to the purpose of transfer coding defined in this section. 3670 </t> 3671 <t> 3672 The registry itself is maintained at 3673 <eref target="http://www.iana.org/assignments/http-parameters"/>. 3674 </t> 3675 </section> 3676 3677 <section title="Transfer Coding Registrations" anchor="transfer.coding.registration"> 3678 <t> 3679 The HTTP Transfer Coding Registry shall be updated with the registrations 3680 below: 3691 3681 </t> 3692 3682 <texttable align="left" suppress-title="true" anchor="iana.transfer.coding.registration.table"> … … 3719 3709 </section> 3720 3710 3711 <section title="Upgrade Token Registry" anchor="upgrade.token.registry"> 3712 <t> 3713 The HTTP Upgrade Token Registry defines the name space for protocol-name 3714 tokens used to identify protocols in the Upgrade header field. 3715 Each registered protocol-name is associated with contact information and 3716 an optional set of specifications that details how the connection 3717 will be processed after it has been upgraded. 3718 </t> 3719 <t> 3720 Registrations require IETF Review (see 3721 <xref target="RFC5226" x:sec="4.1" x:fmt="of"/>) and are subject to the 3722 following rules: 3723 <list style="numbers"> 3724 <t>A protocol-name token, once registered, stays registered forever.</t> 3725 <t>The registration &MUST; name a responsible party for the 3726 registration.</t> 3727 <t>The registration &MUST; name a point of contact.</t> 3728 <t>The registration &MAY; name a set of specifications associated with 3729 that token. Such specifications need not be publicly available.</t> 3730 <t>The registration &SHOULD; name a set of expected "protocol-version" 3731 tokens associated with that token at the time of registration.</t> 3732 <t>The responsible party &MAY; change the registration at any time. 3733 The IANA will keep a record of all such changes, and make them 3734 available upon request.</t> 3735 <t>The IESG &MAY; reassign responsibility for a protocol token. 3736 This will normally only be used in the case when a 3737 responsible party cannot be contacted.</t> 3738 </list> 3739 </t> 3740 <t> 3741 This registration procedure for HTTP Upgrade Tokens replaces that 3742 previously defined in <xref target="RFC2817" x:fmt="of" x:sec="7.2"/>. 3743 </t> 3744 </section> 3745 3721 3746 <section title="Upgrade Token Registration" anchor="upgrade.token.registration"> 3722 3747 <t> 3723 The registration procedure for HTTP Upgrade Tokens — previously defined 3724 in <xref target="RFC2817" x:fmt="of" x:sec="7.2"/> — is now defined 3725 by <xref target="upgrade.token.registry"/> of this document. 3726 </t> 3727 <t> 3728 The HTTP Upgrade Token Registry located at <eref target="http://www.iana.org/assignments/http-upgrade-tokens/"/> 3729 shall be updated with the registration below: 3748 The HTTP Upgrade Token Registry shall be updated with the registration 3749 below: 3730 3750 </t> 3731 3751 <texttable align="left" suppress-title="true"> 3732 3752 <ttcol>Value</ttcol> 3733 3753 <ttcol>Description</ttcol> 3754 <ttcol>Expected Version Tokens</ttcol> 3734 3755 <ttcol>Reference</ttcol> 3735 3756 3736 3757 <c>HTTP</c> 3737 <c>Hypertext Transfer Protocol</c> 3738 <c> <xref target="http.version"/> of this specification</c>3739 3758 <c>Hypertext Transfer Protocol</c> 3759 <c>any DIGIT.DIGIT (e.g, "2.0")</c> 3760 <c><xref target="http.version"/></c> 3740 3761 </texttable> 3762 <t> 3763 The responsible party is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". 3764 </t> 3741 3765 </section> 3742 3766
Note: See TracChangeset
for help on using the changeset viewer.