Changeset 2580
- Timestamp:
- 24/01/14 22:10:35 (8 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2569 r2580 448 448 } 449 449 @bottom-center { 450 content: "Expires July 2 7, 2014";450 content: "Expires July 28, 2014"; 451 451 } 452 452 @bottom-right { … … 490 490 <meta name="dct.creator" content="Reschke, J. F."> 491 491 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 492 <meta name="dct.issued" scheme="ISO8601" content="2014-01-2 3">492 <meta name="dct.issued" scheme="ISO8601" content="2014-01-24"> 493 493 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 519 519 <tr> 520 520 <td class="left">Intended status: Standards Track</td> 521 <td class="right">January 2 3, 2014</td>521 <td class="right">January 24, 2014</td> 522 522 </tr> 523 523 <tr> 524 <td class="left">Expires: July 2 7, 2014</td>524 <td class="left">Expires: July 28, 2014</td> 525 525 <td class="right"></td> 526 526 </tr> … … 551 551 in progress”. 552 552 </p> 553 <p>This Internet-Draft will expire on July 2 7, 2014.</p>553 <p>This Internet-Draft will expire on July 28, 2014.</p> 554 554 </div> 555 555 <div id="rfc.copyrightnotice"> … … 1658 1658 message. 1659 1659 </p> 1660 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span> <span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><a href="#chunked.encoding" class="smpl">chunked-body</a> = *<a href="#chunked.encoding" class="smpl">chunk</a>1660 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span> <a href="#chunked.encoding" class="smpl">chunked-body</a> = *<a href="#chunked.encoding" class="smpl">chunk</a> 1661 1661 <a href="#chunked.encoding" class="smpl">last-chunk</a> 1662 1662 <a href="#chunked.trailer.part" class="smpl">trailer-part</a> … … 1680 1680 of message body size. 1681 1681 </p> 1682 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.6 6"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span> <a href="#chunked.extension" class="smpl">chunk-ext</a> = *( ";" <a href="#chunked.extension" class="smpl">chunk-ext-name</a> [ "=" <a href="#chunked.extension" class="smpl">chunk-ext-val</a> ] )1682 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span> <a href="#chunked.extension" class="smpl">chunk-ext</a> = *( ";" <a href="#chunked.extension" class="smpl">chunk-ext-name</a> [ "=" <a href="#chunked.extension" class="smpl">chunk-ext-val</a> ] ) 1683 1683 1684 1684 <a href="#chunked.extension" class="smpl">chunk-ext-name</a> = <a href="#rule.token.separators" class="smpl">token</a> … … 1701 1701 header section. 1702 1702 </p> 1703 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.77"></span> <a href="#chunked.trailer.part" class="smpl">trailer-part</a> = *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> ) 1704 </pre><p id="rfc.section.4.1.2.p.3">A sender <em class="bcp14">MUST NOT</em> generate a trailer that contains a field which needs to be known by the recipient before it can begin processing the message 1705 body. For example, most recipients need to know the values of <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> and <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> in order to select a content handler, so placing those fields in a trailer would force the recipient to buffer the entire 1706 body before it could begin, greatly increasing user-perceived latency and defeating one of the main advantages of using chunked 1707 to send data streams of unknown length. A sender <em class="bcp14">MUST NOT</em> generate a trailer containing a <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>, <a href="#header.content-length" class="smpl">Content-Length</a>, or <a href="#header.trailer" class="smpl">Trailer</a> field. 1708 </p> 1709 <p id="rfc.section.4.1.2.p.4">A server <em class="bcp14">MUST</em> generate an empty trailer with the chunked transfer coding unless at least one of the following is true: 1710 </p> 1711 <ol> 1712 <li>the request included a <a href="#header.te" class="smpl">TE</a> header field that indicates "trailers" is acceptable in the transfer coding of the response, as described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section 4.3</a>; or, 1713 </li> 1714 <li>the trailer fields consist entirely of optional metadata and the recipient could use the message (in a manner acceptable to 1715 the generating server) without receiving that metadata. In other words, the generating server is willing to accept the possibility 1716 that the trailer fields might be silently discarded along the path to the client. 1717 </li> 1718 </ol> 1719 <p id="rfc.section.4.1.2.p.5">The above requirement prevents the need for an infinite buffer when a message is being received by an HTTP/1.1 (or later) 1720 proxy and forwarded to an HTTP/1.0 recipient. 1703 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span> <a href="#chunked.trailer.part" class="smpl">trailer-part</a> = *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> ) 1704 </pre><p id="rfc.section.4.1.2.p.3">A sender <em class="bcp14">MUST NOT</em> generate a trailer that contains a field necessary for message framing (e.g., <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> and <a href="#header.content-length" class="smpl">Content-Length</a>), routing (e.g., <a href="#header.host" class="smpl">Host</a>), request modifiers (e.g., controls and conditionals in <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 5</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), authentication (e.g., see <a href="#Part7" id="rfc.xref.Part7.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a> and <a href="#RFC6265" id="rfc.xref.RFC6265.3"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a>), response control data (e.g., see <a href="p2-semantics.html#response.control.data" title="Control Data">Section 7.1</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), or determining how to process the payload (e.g., <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a>, <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a>, <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a>, and <a href="#header.trailer" class="smpl">Trailer</a>). 1705 </p> 1706 <p id="rfc.section.4.1.2.p.4">When a chunked message containing a non-empty trailer is received, the recipient <em class="bcp14">MAY</em> process the fields (aside from those forbidden above) as if they were appended to the message's header section. A recipient <em class="bcp14">MUST</em> ignore (or consider as an error) any fields that are forbidden to be sent in a trailer, since processing them as if they were 1707 present in the header section might bypass external security filters. 1708 </p> 1709 <p id="rfc.section.4.1.2.p.5">Unless the request includes a <a href="#header.te" class="smpl">TE</a> header field indicating "trailers" is acceptable, as described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section 4.3</a>, a server <em class="bcp14">SHOULD NOT</em> generate trailer fields that it believes are necessary for the user agent to receive. Without a TE containing "trailers", 1710 the server ought to assume that the trailer fields might be silently discarded along the path to the user agent. This requirement 1711 allows intermediaries to forward a de-chunked message to an HTTP/1.0 recipient without buffering the entire response. 1721 1712 </p> 1722 1713 </div> … … 1732 1723 read chunk-size, chunk-ext (if any), and CRLF 1733 1724 } 1734 read header-field 1735 while (header-field not empty) { 1736 append header-field to existing header fields 1737 read header-field 1725 read trailer field 1726 while (trailer field is not empty) { 1727 if trailer field is allowed to be sent in a trailer, 1728 append trailer field to existing header fields 1729 read trailer-field 1738 1730 } 1739 1731 Content-Length := length … … 1762 1754 </div> 1763 1755 <div id="gzip.coding"> 1764 <div id="rfc.iref.g.7 8"></div>1756 <div id="rfc.iref.g.70"></div> 1765 1757 <h3 id="rfc.section.4.2.3"><a href="#rfc.section.4.2.3">4.2.3</a> <a href="#gzip.coding">Gzip Coding</a></h3> 1766 1758 <p id="rfc.section.4.2.3.p.1">The "gzip" coding is an LZ77 coding with a 32 bit CRC that is commonly produced by the gzip file compression program <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. A recipient <em class="bcp14">SHOULD</em> consider "x-gzip" to be equivalent to "gzip". … … 1777 1769 described in <a href="#transfer.codings" title="Transfer Codings">Section 4</a>), and/or the keyword "trailers". A client <em class="bcp14">MUST NOT</em> send the chunked transfer coding name in TE; chunked is always acceptable for HTTP/1.1 recipients. 1778 1770 </p> 1779 <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.7 9"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span> <a href="#header.te" class="smpl">TE</a> = #<a href="#header.te" class="smpl">t-codings</a>1771 <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.71"></span><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span> <a href="#header.te" class="smpl">TE</a> = #<a href="#header.te" class="smpl">t-codings</a> 1780 1772 <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-coding</a> [ <a href="#header.te" class="smpl">t-ranking</a> ] ) 1781 1773 <a href="#header.te" class="smpl">t-ranking</a> = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> "q=" <a href="#header.te" class="smpl">rank</a> … … 1793 1785 </p> 1794 1786 <p id="rfc.section.4.3.p.7">When multiple transfer codings are acceptable, the client <em class="bcp14">MAY</em> rank the codings by preference using a case-insensitive "q" parameter (similar to the qvalues used in content negotiation 1795 fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 5.3.1</a> of <a href="#Part2" id="rfc.xref.Part2. 19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred;1787 fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 5.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred; 1796 1788 a value of 0 means "not acceptable". 1797 1789 </p> … … 1810 1802 and the recipient wishes to confirm an integrity check on the fly. 1811 1803 </p> 1812 <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g. 83"></span> <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>1804 <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span> <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a> 1813 1805 </pre></div> 1814 1806 </div> … … 1828 1820 </p> 1829 1821 <p id="rfc.section.5.1.p.2">HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which 1830 are defined in <a href="#Part2" id="rfc.xref.Part2.2 0"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section 2.7</a>) is typically used as an identifier for the "<dfn>target resource</dfn>", which a user agent would resolve to its absolute form in order to obtain the "<dfn>target URI</dfn>". The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side1822 are defined in <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section 2.7</a>) is typically used as an identifier for the "<dfn>target resource</dfn>", which a user agent would resolve to its absolute form in order to obtain the "<dfn>target URI</dfn>". The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side 1831 1823 processing (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>). 1832 1824 </p> … … 1857 1849 both the method being requested and whether the request is to a proxy. 1858 1850 </p> 1859 <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g. 84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span> <a href="#request-target" class="smpl">request-target</a> = <a href="#origin-form" class="smpl">origin-form</a>1851 <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span> <a href="#request-target" class="smpl">request-target</a> = <a href="#origin-form" class="smpl">origin-form</a> 1860 1852 / <a href="#absolute-form" class="smpl">absolute-form</a> 1861 1853 / <a href="#authority-form" class="smpl">authority-form</a> … … 1898 1890 </p> 1899 1891 </div> 1900 <p id="rfc.section.5.3.p.16">The <dfn>authority-form</dfn> of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.2 1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo and its "@" delimiter) as the request-target. For example,1892 <p id="rfc.section.5.3.p.16">The <dfn>authority-form</dfn> of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo and its "@" delimiter) as the request-target. For example, 1901 1893 </p> 1902 1894 <div id="rfc.figure.u.42"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1 … … 1905 1897 </p> 1906 1898 </div> 1907 <p id="rfc.section.5.3.p.19">The <dfn>asterisk-form</dfn> of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 4.3.7</a> of <a href="#Part2" id="rfc.xref.Part2.2 2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,1899 <p id="rfc.section.5.3.p.19">The <dfn>asterisk-form</dfn> of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 4.3.7</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server, 1908 1900 the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example, 1909 1901 </p> … … 1925 1917 to distinguish among resources while servicing requests for multiple host names on a single IP address. 1926 1918 </p> 1927 <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.8 9"></span> <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 2.7.1</a>1919 <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.82"></span> <a href="#header.host" class="smpl">Host</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 2.7.1</a> 1928 1920 </pre><p id="rfc.section.5.4.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target URI includes an authority component, then a client <em class="bcp14">MUST</em> send a field-value for Host that is identical to that authority component, excluding any userinfo subcomponent and its "@" 1929 1921 delimiter (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>). If the authority component is missing or undefined for the target URI, then a client <em class="bcp14">MUST</em> send a Host header field with an empty field-value. … … 1993 1985 <p id="rfc.section.5.6.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response 1994 1986 messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made 1995 on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 6.2</a> of <a href="#Part2" id="rfc.xref.Part2.2 3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) precede a final response to the same request.1987 on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 6.2</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) precede a final response to the same request. 1996 1988 </p> 1997 1989 <p id="rfc.section.5.6.p.2">A client that has more than one outstanding request on a connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent and <em class="bcp14">MUST</em> associate each received response message on that connection to the highest ordered request that has not yet received a final … … 2019 2011 along the request/response chain. 2020 2012 </p> 2021 <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g. 90"></span><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span> <a href="#header.via" class="smpl">Via</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )2013 <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span> <a href="#header.via" class="smpl">Via</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) 2022 2014 2023 2015 <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.upgrade" class="smpl">protocol-name</a> "/" ] <a href="#header.upgrade" class="smpl">protocol-version</a> … … 2083 2075 selected representation. A proxy <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>). 2084 2076 </p> 2085 <p id="rfc.section.5.7.2.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#Part2" id="rfc.xref.Part2.2 4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) of a message that contains a no-transform cache-control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).2077 <p id="rfc.section.5.7.2.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the payload (<a href="p2-semantics.html#payload" title="Payload Semantics">Section 3.3</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) of a message that contains a no-transform cache-control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 5.2</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 2086 2078 </p> 2087 2079 <p id="rfc.section.5.7.2.p.7">A proxy <em class="bcp14">MAY</em> transform the payload of a message that does not contain a no-transform cache-control directive. A proxy that transforms a 2088 2080 payload <em class="bcp14">MUST</em> add a Warning header field with the warn-code of 214 ("Transformation Applied") if one is not already in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 5.5</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A proxy that transforms the payload of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response can further inform downstream recipients that a transformation has been applied by changing the response status code 2089 to <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a> (<a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 6.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.2 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).2081 to <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative Information)</a> (<a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 6.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 2090 2082 </p> 2091 2083 </div> … … 2124 2116 </p> 2125 2117 <p id="rfc.section.6.1.p.4">The Connection header field's value has the following grammar:</p> 2126 <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g. 96"></span><span id="rfc.iref.g.97"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-option</a>2118 <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-option</a> 2127 2119 <a href="#header.connection" class="smpl">connection-option</a> = <a href="#rule.token.separators" class="smpl">token</a> 2128 2120 </pre><p id="rfc.section.6.1.p.6">Connection options are case-insensitive.</p> … … 2191 2183 </p> 2192 2184 <p id="rfc.section.6.3.1.p.2">When an inbound connection is closed prematurely, a client <em class="bcp14">MAY</em> open a new connection and automatically retransmit an aborted sequence of requests if all of those requests have idempotent 2193 methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.2 6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A proxy <em class="bcp14">MUST NOT</em> automatically retry non-idempotent requests.2185 methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). A proxy <em class="bcp14">MUST NOT</em> automatically retry non-idempotent requests. 2194 2186 </p> 2195 2187 <p id="rfc.section.6.3.1.p.3">A user agent <em class="bcp14">MUST NOT</em> automatically retry a request with a non-idempotent method unless it has some means to know that the request semantics are … … 2205 2197 <div id="pipelining"> 2206 2198 <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a> <a href="#pipelining">Pipelining</a></h3> 2207 <p id="rfc.section.6.3.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "<dfn>pipeline</dfn>" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MAY</em> process a sequence of pipelined requests in parallel if they all have safe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.2 7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), but <em class="bcp14">MUST</em> send the corresponding responses in the same order that the requests were received.2199 <p id="rfc.section.6.3.2.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "<dfn>pipeline</dfn>" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MAY</em> process a sequence of pipelined requests in parallel if they all have safe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), but <em class="bcp14">MUST</em> send the corresponding responses in the same order that the requests were received. 2208 2200 </p> 2209 2201 <p id="rfc.section.6.3.2.p.2">A client that pipelines requests <em class="bcp14">SHOULD</em> retry unanswered requests if the connection closes before it receives all of the corresponding responses. When retrying pipelined … … 2212 2204 problem described in <a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.2" title="Tear-down">Section 6.6</a>). 2213 2205 </p> 2214 <p id="rfc.section.6.3.2.p.3">Idempotent methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2. 28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) are significant to pipelining because they can be automatically retried after a connection failure. A user agent <em class="bcp14">SHOULD NOT</em> pipeline requests after a non-idempotent method, until the final response status code for that method has been received, unless2206 <p id="rfc.section.6.3.2.p.3">Idempotent methods (<a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) are significant to pipelining because they can be automatically retried after a connection failure. A user agent <em class="bcp14">SHOULD NOT</em> pipeline requests after a non-idempotent method, until the final response status code for that method has been received, unless 2215 2207 the user agent has a means to detect and recover from partial failure conditions involving the pipelined sequence. 2216 2208 </p> … … 2293 2285 in order of descending preference, before sending the final response. A server <em class="bcp14">MAY</em> ignore a received Upgrade header field if it wishes to continue using the current protocol on that connection. 2294 2286 </p> 2295 <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.9 8"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#header.upgrade" class="smpl">protocol</a>2287 <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.91"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#header.upgrade" class="smpl">protocol</a> 2296 2288 2297 2289 <a href="#header.upgrade" class="smpl">protocol</a> = <a href="#header.upgrade" class="smpl">protocol-name</a> ["/" <a href="#header.upgrade" class="smpl">protocol-version</a>] … … 2336 2328 </p> 2337 2329 <p id="rfc.section.6.7.p.11">A client cannot begin using an upgraded protocol on the connection until it has completely sent the request message (i.e., 2338 the client can't change the protocol it is sending in the middle of a message). If a server receives both Upgrade and an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation (<a href="p2-semantics.html#header.expect" title="Expect">Section 5.1.1</a> of <a href="#Part2" id="rfc.xref.Part2. 29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), the server <em class="bcp14">MUST</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> response.2330 the client can't change the protocol it is sending in the middle of a message). If a server receives both Upgrade and an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation (<a href="p2-semantics.html#header.expect" title="Expect">Section 5.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), the server <em class="bcp14">MUST</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> response. 2339 2331 </p> 2340 2332 <p id="rfc.section.6.7.p.12">The Upgrade header field only applies to switching protocols on top of the existing connection; it cannot be used to switch 2341 2333 the underlying connection (transport) protocol, nor to switch the existing communication to a different connection. For those 2342 purposes, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.3 0"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).2334 purposes, it is more appropriate to use a <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). 2343 2335 </p> 2344 2336 <p id="rfc.section.6.7.p.13">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined … … 2672 2664 <li>Pointer to specification text</li> 2673 2665 </ul> 2674 <p id="rfc.section.8.4.1.p.2">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.3 1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>.2666 <p id="rfc.section.8.4.1.p.2">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>. 2675 2667 </p> 2676 2668 <p id="rfc.section.8.4.1.p.3">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 specification. … … 2845 2837 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a href="#security.considerations">Security Considerations</a></h1> 2846 2838 <p id="rfc.section.9.p.1">This section is meant to inform developers, information providers, and users of known security considerations relevant to 2847 HTTP message syntax, parsing, and routing. Security considerations about HTTP semantics and payloads are addressed in <a href="#Part2" id="rfc.xref.Part2.3 2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.2839 HTTP message syntax, parsing, and routing. Security considerations about HTTP semantics and payloads are addressed in <a href="#Part2" id="rfc.xref.Part2.34"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>. 2848 2840 </p> 2849 2841 <div id="dns.related.attacks"> … … 2878 2870 that most implementations will choose substantially higher limits. 2879 2871 </p> 2880 <p id="rfc.section.9.3.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.3 3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.34"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>.2872 <p id="rfc.section.9.3.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.35"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.36"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>. 2881 2873 </p> 2882 2874 <p id="rfc.section.9.3.p.4">Recipients ought to carefully limit the extent to which they read other fields, including (but not limited to) request methods, … … 3509 3501 <li><tt>Grammar</tt> 3510 3502 <ul> 3511 <li><tt>absolute-form</tt> <a href="#rfc.iref.g. 86"><b>5.3</b></a></li>3503 <li><tt>absolute-form</tt> <a href="#rfc.iref.g.79"><b>5.3</b></a></li> 3512 3504 <li><tt>absolute-path</tt> <a href="#rfc.iref.g.19"><b>2.7</b></a></li> 3513 3505 <li><tt>absolute-URI</tt> <a href="#rfc.iref.g.17"><b>2.7</b></a></li> 3514 3506 <li>ALPHA <a href="#rfc.iref.g.1"><b>1.2</b></a></li> 3515 <li><tt>asterisk-form</tt> <a href="#rfc.iref.g.8 8"><b>5.3</b></a></li>3507 <li><tt>asterisk-form</tt> <a href="#rfc.iref.g.81"><b>5.3</b></a></li> 3516 3508 <li><tt>authority</tt> <a href="#rfc.iref.g.18"><b>2.7</b></a></li> 3517 <li><tt>authority-form</tt> <a href="#rfc.iref.g.8 7"><b>5.3</b></a></li>3509 <li><tt>authority-form</tt> <a href="#rfc.iref.g.80"><b>5.3</b></a></li> 3518 3510 <li><tt>BWS</tt> <a href="#rfc.iref.g.42"><b>3.2.3</b></a></li> 3519 <li><tt>chunk</tt> <a href="#rfc.iref.g.58"><b>4.1</b></a> , <a href="#rfc.iref.g.67"><b>4.1.1</b></a></li>3520 <li><tt>chunk-data</tt> <a href="#rfc.iref.g.6 4"><b>4.1</b></a>, <a href="#rfc.iref.g.73"><b>4.1.1</b></a></li>3521 <li><tt>chunk-ext</tt> <a href="#rfc.iref.g.6 1"><b>4.1</b></a>, <a href="#rfc.iref.g.70"><b>4.1.1</b></a></li>3522 <li><tt>chunk-ext-name</tt> <a href="#rfc.iref.g.6 2"><b>4.1</b></a>, <a href="#rfc.iref.g.71"><b>4.1.1</b></a></li>3523 <li><tt>chunk-ext-val</tt> <a href="#rfc.iref.g.6 3"><b>4.1</b></a>, <a href="#rfc.iref.g.72"><b>4.1.1</b></a></li>3524 <li><tt>chunk-size</tt> <a href="#rfc.iref.g.59"><b>4.1</b></a> , <a href="#rfc.iref.g.68"><b>4.1.1</b></a></li>3525 <li><tt>chunked-body</tt> <a href="#rfc.iref.g.57"><b>4.1</b></a>, <a href="#rfc.iref.g.6 6"><b>4.1.1</b></a></li>3511 <li><tt>chunk</tt> <a href="#rfc.iref.g.58"><b>4.1</b></a></li> 3512 <li><tt>chunk-data</tt> <a href="#rfc.iref.g.63"><b>4.1</b></a></li> 3513 <li><tt>chunk-ext</tt> <a href="#rfc.iref.g.62">4.1</a>, <a href="#rfc.iref.g.65"><b>4.1.1</b></a></li> 3514 <li><tt>chunk-ext-name</tt> <a href="#rfc.iref.g.66"><b>4.1.1</b></a></li> 3515 <li><tt>chunk-ext-val</tt> <a href="#rfc.iref.g.67"><b>4.1.1</b></a></li> 3516 <li><tt>chunk-size</tt> <a href="#rfc.iref.g.59"><b>4.1</b></a></li> 3517 <li><tt>chunked-body</tt> <a href="#rfc.iref.g.57"><b>4.1</b></a>, <a href="#rfc.iref.g.64"><b>4.1.1</b></a></li> 3526 3518 <li><tt>comment</tt> <a href="#rfc.iref.g.48"><b>3.2.6</b></a></li> 3527 <li><tt>Connection</tt> <a href="#rfc.iref.g. 96"><b>6.1</b></a></li>3528 <li><tt>connection-option</tt> <a href="#rfc.iref.g.9 7"><b>6.1</b></a></li>3519 <li><tt>Connection</tt> <a href="#rfc.iref.g.89"><b>6.1</b></a></li> 3520 <li><tt>connection-option</tt> <a href="#rfc.iref.g.90"><b>6.1</b></a></li> 3529 3521 <li><tt>Content-Length</tt> <a href="#rfc.iref.g.53"><b>3.3.2</b></a></li> 3530 3522 <li>CR <a href="#rfc.iref.g.2"><b>1.2</b></a></li> … … 3535 3527 <li>DQUOTE <a href="#rfc.iref.g.6"><b>1.2</b></a></li> 3536 3528 <li><tt>field-content</tt> <a href="#rfc.iref.g.38"><b>3.2</b></a></li> 3537 <li><tt>field-name</tt> <a href="#rfc.iref.g.36"><b>3.2</b></a> </li>3529 <li><tt>field-name</tt> <a href="#rfc.iref.g.36"><b>3.2</b></a>, <a href="#rfc.iref.g.76">4.4</a></li> 3538 3530 <li><tt>field-value</tt> <a href="#rfc.iref.g.37"><b>3.2</b></a></li> 3539 3531 <li><tt>fragment</tt> <a href="#rfc.iref.g.22"><b>2.7</b></a></li> 3540 <li><tt>header-field</tt> <a href="#rfc.iref.g.35"><b>3.2</b></a> </li>3532 <li><tt>header-field</tt> <a href="#rfc.iref.g.35"><b>3.2</b></a>, <a href="#rfc.iref.g.69">4.1.2</a></li> 3541 3533 <li>HEXDIG <a href="#rfc.iref.g.7"><b>1.2</b></a></li> 3542 <li><tt>Host</tt> <a href="#rfc.iref.g.8 9"><b>5.4</b></a></li>3534 <li><tt>Host</tt> <a href="#rfc.iref.g.82"><b>5.4</b></a></li> 3543 3535 <li>HTAB <a href="#rfc.iref.g.8"><b>1.2</b></a></li> 3544 3536 <li><tt>HTTP-message</tt> <a href="#rfc.iref.g.28"><b>3</b></a></li> … … 3547 3539 <li><tt>HTTP-version</tt> <a href="#rfc.iref.g.14"><b>2.6</b></a></li> 3548 3540 <li><tt>https-URI</tt> <a href="#rfc.iref.g.27"><b>2.7.2</b></a></li> 3549 <li><tt>last-chunk</tt> <a href="#rfc.iref.g.60"><b>4.1</b></a> , <a href="#rfc.iref.g.69"><b>4.1.1</b></a></li>3541 <li><tt>last-chunk</tt> <a href="#rfc.iref.g.60"><b>4.1</b></a></li> 3550 3542 <li>LF <a href="#rfc.iref.g.9"><b>1.2</b></a></li> 3551 3543 <li><tt>message-body</tt> <a href="#rfc.iref.g.51"><b>3.3</b></a></li> … … 3554 3546 <li><tt>obs-text</tt> <a href="#rfc.iref.g.47"><b>3.2.6</b></a></li> 3555 3547 <li>OCTET <a href="#rfc.iref.g.10"><b>1.2</b></a></li> 3556 <li><tt>origin-form</tt> <a href="#rfc.iref.g. 85"><b>5.3</b></a></li>3548 <li><tt>origin-form</tt> <a href="#rfc.iref.g.78"><b>5.3</b></a></li> 3557 3549 <li><tt>OWS</tt> <a href="#rfc.iref.g.40"><b>3.2.3</b></a></li> 3558 3550 <li><tt>partial-URI</tt> <a href="#rfc.iref.g.25"><b>2.7</b></a></li> 3559 3551 <li><tt>port</tt> <a href="#rfc.iref.g.20"><b>2.7</b></a></li> 3560 <li><tt>protocol-name</tt> <a href="#rfc.iref.g. 92"><b>5.7.1</b></a></li>3561 <li><tt>protocol-version</tt> <a href="#rfc.iref.g. 93"><b>5.7.1</b></a></li>3562 <li><tt>pseudonym</tt> <a href="#rfc.iref.g. 95"><b>5.7.1</b></a></li>3552 <li><tt>protocol-name</tt> <a href="#rfc.iref.g.85"><b>5.7.1</b></a></li> 3553 <li><tt>protocol-version</tt> <a href="#rfc.iref.g.86"><b>5.7.1</b></a></li> 3554 <li><tt>pseudonym</tt> <a href="#rfc.iref.g.88"><b>5.7.1</b></a></li> 3563 3555 <li><tt>qdtext</tt> <a href="#rfc.iref.g.46"><b>3.2.6</b></a></li> 3564 <li><tt>qdtext-nf</tt> <a href="#rfc.iref.g.76"><b>4.1.1</b></a></li>3565 3556 <li><tt>query</tt> <a href="#rfc.iref.g.21"><b>2.7</b></a></li> 3566 3557 <li><tt>quoted-pair</tt> <a href="#rfc.iref.g.50"><b>3.2.6</b></a></li> 3567 <li><tt>quoted-str-nf</tt> <a href="#rfc.iref.g.75"><b>4.1.1</b></a></li>3568 3558 <li><tt>quoted-string</tt> <a href="#rfc.iref.g.45"><b>3.2.6</b></a></li> 3569 <li><tt>rank</tt> <a href="#rfc.iref.g. 82"><b>4.3</b></a></li>3559 <li><tt>rank</tt> <a href="#rfc.iref.g.74"><b>4.3</b></a></li> 3570 3560 <li><tt>reason-phrase</tt> <a href="#rfc.iref.g.34"><b>3.1.2</b></a></li> 3571 <li><tt>received-by</tt> <a href="#rfc.iref.g. 94"><b>5.7.1</b></a></li>3572 <li><tt>received-protocol</tt> <a href="#rfc.iref.g. 91"><b>5.7.1</b></a></li>3561 <li><tt>received-by</tt> <a href="#rfc.iref.g.87"><b>5.7.1</b></a></li> 3562 <li><tt>received-protocol</tt> <a href="#rfc.iref.g.84"><b>5.7.1</b></a></li> 3573 3563 <li><tt>request-line</tt> <a href="#rfc.iref.g.30"><b>3.1.1</b></a></li> 3574 <li><tt>request-target</tt> <a href="#rfc.iref.g. 84"><b>5.3</b></a></li>3564 <li><tt>request-target</tt> <a href="#rfc.iref.g.77"><b>5.3</b></a></li> 3575 3565 <li><tt>RWS</tt> <a href="#rfc.iref.g.41"><b>3.2.3</b></a></li> 3576 3566 <li><tt>segment</tt> <a href="#rfc.iref.g.23"><b>2.7</b></a></li> … … 3579 3569 <li><tt>status-code</tt> <a href="#rfc.iref.g.33"><b>3.1.2</b></a></li> 3580 3570 <li><tt>status-line</tt> <a href="#rfc.iref.g.32"><b>3.1.2</b></a></li> 3581 <li><tt>t-codings</tt> <a href="#rfc.iref.g. 80"><b>4.3</b></a></li>3582 <li><tt>t-ranking</tt> <a href="#rfc.iref.g. 81"><b>4.3</b></a></li>3571 <li><tt>t-codings</tt> <a href="#rfc.iref.g.72"><b>4.3</b></a></li> 3572 <li><tt>t-ranking</tt> <a href="#rfc.iref.g.73"><b>4.3</b></a></li> 3583 3573 <li><tt>tchar</tt> <a href="#rfc.iref.g.44"><b>3.2.6</b></a></li> 3584 <li><tt>TE</tt> <a href="#rfc.iref.g.7 9"><b>4.3</b></a></li>3574 <li><tt>TE</tt> <a href="#rfc.iref.g.71"><b>4.3</b></a></li> 3585 3575 <li><tt>token</tt> <a href="#rfc.iref.g.43"><b>3.2.6</b></a></li> 3586 <li><tt>Trailer</tt> <a href="#rfc.iref.g. 83"><b>4.4</b></a></li>3587 <li><tt>trailer-part</tt> <a href="#rfc.iref.g.6 5">4.1</a>, <a href="#rfc.iref.g.74">4.1.1</a>, <a href="#rfc.iref.g.77"><b>4.1.2</b></a></li>3576 <li><tt>Trailer</tt> <a href="#rfc.iref.g.75"><b>4.4</b></a></li> 3577 <li><tt>trailer-part</tt> <a href="#rfc.iref.g.61">4.1</a>, <a href="#rfc.iref.g.68"><b>4.1.2</b></a></li> 3588 3578 <li><tt>transfer-coding</tt> <a href="#rfc.iref.g.54"><b>4</b></a></li> 3589 3579 <li><tt>Transfer-Encoding</tt> <a href="#rfc.iref.g.52"><b>3.3.1</b></a></li> 3590 3580 <li><tt>transfer-extension</tt> <a href="#rfc.iref.g.55"><b>4</b></a></li> 3591 3581 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.56"><b>4</b></a></li> 3592 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.9 8"><b>6.7</b></a></li>3582 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.91"><b>6.7</b></a></li> 3593 3583 <li><tt>uri-host</tt> <a href="#rfc.iref.g.24"><b>2.7</b></a></li> 3594 3584 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.16"><b>2.7</b></a></li> 3595 3585 <li>VCHAR <a href="#rfc.iref.g.12"><b>1.2</b></a></li> 3596 <li><tt>Via</tt> <a href="#rfc.iref.g. 90"><b>5.7.1</b></a></li>3586 <li><tt>Via</tt> <a href="#rfc.iref.g.83"><b>5.7.1</b></a></li> 3597 3587 </ul> 3598 3588 </li> 3599 <li>gzip (Coding Format) <a href="#rfc.iref.g.7 8">4.2.3</a></li>3589 <li>gzip (Coding Format) <a href="#rfc.iref.g.70">4.2.3</a></li> 3600 3590 </ul> 3601 3591 </li> … … 3643 3633 </li> 3644 3634 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3645 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.1</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3</a>, <a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.15">3.3.1</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">3.3.2</a>, <a href="#rfc.xref.Part2.18">3.3.2</a>, <a href="#rfc.xref.Part2.19">4. 3</a>, <a href="#rfc.xref.Part2.20">5.1</a>, <a href="#rfc.xref.Part2.21">5.3</a>, <a href="#rfc.xref.Part2.22">5.3</a>, <a href="#rfc.xref.Part2.23">5.6</a>, <a href="#rfc.xref.Part2.24">5.7.2</a>, <a href="#rfc.xref.Part2.25">5.7.2</a>, <a href="#rfc.xref.Part2.26">6.3.1</a>, <a href="#rfc.xref.Part2.27">6.3.2</a>, <a href="#rfc.xref.Part2.28">6.3.2</a>, <a href="#rfc.xref.Part2.29">6.7</a>, <a href="#rfc.xref.Part2.30">6.7</a>, <a href="#rfc.xref.Part2.31">8.4.1</a>, <a href="#rfc.xref.Part2.32">9</a>, <a href="#rfc.xref.Part2.33">9.3</a>, <a href="#rfc.xref.Part2.34">9.3</a>, <a href="#Part2"><b>11.1</b></a><ul>3635 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.1</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3</a>, <a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.15">3.3.1</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">3.3.2</a>, <a href="#rfc.xref.Part2.18">3.3.2</a>, <a href="#rfc.xref.Part2.19">4.1.2</a>, <a href="#rfc.xref.Part2.20">4.1.2</a>, <a href="#rfc.xref.Part2.21">4.3</a>, <a href="#rfc.xref.Part2.22">5.1</a>, <a href="#rfc.xref.Part2.23">5.3</a>, <a href="#rfc.xref.Part2.24">5.3</a>, <a href="#rfc.xref.Part2.25">5.6</a>, <a href="#rfc.xref.Part2.26">5.7.2</a>, <a href="#rfc.xref.Part2.27">5.7.2</a>, <a href="#rfc.xref.Part2.28">6.3.1</a>, <a href="#rfc.xref.Part2.29">6.3.2</a>, <a href="#rfc.xref.Part2.30">6.3.2</a>, <a href="#rfc.xref.Part2.31">6.7</a>, <a href="#rfc.xref.Part2.32">6.7</a>, <a href="#rfc.xref.Part2.33">8.4.1</a>, <a href="#rfc.xref.Part2.34">9</a>, <a href="#rfc.xref.Part2.35">9.3</a>, <a href="#rfc.xref.Part2.36">9.3</a>, <a href="#Part2"><b>11.1</b></a><ul> 3646 3636 <li><em>Section 2</em> <a href="#rfc.xref.Part2.4">2.7</a></li> 3647 3637 <li><em>Section 3</em> <a href="#rfc.xref.Part2.16">3.3.2</a></li> 3648 <li><em>Section 3.1.2.1</em> <a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.3 1">8.4.1</a></li>3649 <li><em>Section 3.3</em> <a href="#rfc.xref.Part2.2 4">5.7.2</a></li>3638 <li><em>Section 3.1.2.1</em> <a href="#rfc.xref.Part2.14">3.3.1</a>, <a href="#rfc.xref.Part2.33">8.4.1</a></li> 3639 <li><em>Section 3.3</em> <a href="#rfc.xref.Part2.26">5.7.2</a></li> 3650 3640 <li><em>Section 4</em> <a href="#rfc.xref.Part2.6">3.1.1</a></li> 3651 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part2.2 7">6.3.2</a></li>3652 <li><em>Section 4.2.2</em> <a href="#rfc.xref.Part2.2 6">6.3.1</a>, <a href="#rfc.xref.Part2.28">6.3.2</a></li>3641 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part2.29">6.3.2</a></li> 3642 <li><em>Section 4.2.2</em> <a href="#rfc.xref.Part2.28">6.3.1</a>, <a href="#rfc.xref.Part2.30">6.3.2</a></li> 3653 3643 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part2.3">2.1</a>, <a href="#rfc.xref.Part2.12">3.3</a></li> 3654 3644 <li><em>Section 4.3.2</em> <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.17">3.3.2</a></li> 3655 <li><em>Section 4.3.6</em> <a href="#rfc.xref.Part2.13">3.3</a>, <a href="#rfc.xref.Part2.15">3.3.1</a>, <a href="#rfc.xref.Part2.18">3.3.2</a>, <a href="#rfc.xref.Part2.21">5.3</a></li> 3656 <li><em>Section 4.3.7</em> <a href="#rfc.xref.Part2.22">5.3</a></li> 3657 <li><em>Section 5.1.1</em> <a href="#rfc.xref.Part2.29">6.7</a></li> 3658 <li><em>Section 5.3.1</em> <a href="#rfc.xref.Part2.19">4.3</a></li> 3645 <li><em>Section 4.3.6</em> <a href="#rfc.xref.Part2.13">3.3</a>, <a href="#rfc.xref.Part2.15">3.3.1</a>, <a href="#rfc.xref.Part2.18">3.3.2</a>, <a href="#rfc.xref.Part2.23">5.3</a></li> 3646 <li><em>Section 4.3.7</em> <a href="#rfc.xref.Part2.24">5.3</a></li> 3647 <li><em>Section 5</em> <a href="#rfc.xref.Part2.19">4.1.2</a></li> 3648 <li><em>Section 5.1.1</em> <a href="#rfc.xref.Part2.31">6.7</a></li> 3649 <li><em>Section 5.3.1</em> <a href="#rfc.xref.Part2.21">4.3</a></li> 3659 3650 <li><em>Section 6</em> <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a></li> 3660 <li><em>Section 6.2</em> <a href="#rfc.xref.Part2.23">5.6</a></li> 3661 <li><em>Section 6.3.4</em> <a href="#rfc.xref.Part2.25">5.7.2</a></li> 3662 <li><em>Section 6.4</em> <a href="#rfc.xref.Part2.30">6.7</a></li> 3663 <li><em>Section 6.5</em> <a href="#rfc.xref.Part2.34">9.3</a></li> 3664 <li><em>Section 6.5.12</em> <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.33">9.3</a></li> 3651 <li><em>Section 6.2</em> <a href="#rfc.xref.Part2.25">5.6</a></li> 3652 <li><em>Section 6.3.4</em> <a href="#rfc.xref.Part2.27">5.7.2</a></li> 3653 <li><em>Section 6.4</em> <a href="#rfc.xref.Part2.32">6.7</a></li> 3654 <li><em>Section 6.5</em> <a href="#rfc.xref.Part2.36">9.3</a></li> 3655 <li><em>Section 6.5.12</em> <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.35">9.3</a></li> 3656 <li><em>Section 7.1</em> <a href="#rfc.xref.Part2.20">4.1.2</a></li> 3665 3657 <li><em>Section 7.1.1.2</em> <a href="#rfc.xref.Part2.9">3.2</a></li> 3666 3658 <li><em>Section 8.3</em> <a href="#rfc.xref.Part2.10">3.2.1</a></li> … … 3680 3672 </ul> 3681 3673 </li> 3682 <li><em>Part7</em> <a href="#rfc.xref.Part7.1">1</a>, <a href="# Part7"><b>11.1</b></a></li>3674 <li><em>Part7</em> <a href="#rfc.xref.Part7.1">1</a>, <a href="#rfc.xref.Part7.2">4.1.2</a>, <a href="#Part7"><b>11.1</b></a></li> 3683 3675 <li>proxy <a href="#rfc.iref.p.1"><b>2.3</b></a></li> 3684 3676 </ul> … … 3752 3744 </ul> 3753 3745 </li> 3754 <li><em>RFC6265</em> <a href="#rfc.xref.RFC6265.1">2.7.2</a>, <a href="#rfc.xref.RFC6265.2">3.2.2</a>, <a href="# RFC6265"><b>11.2</b></a></li>3746 <li><em>RFC6265</em> <a href="#rfc.xref.RFC6265.1">2.7.2</a>, <a href="#rfc.xref.RFC6265.2">3.2.2</a>, <a href="#rfc.xref.RFC6265.3">4.1.2</a>, <a href="#RFC6265"><b>11.2</b></a></li> 3755 3747 <li><em>RFC6585</em> <a href="#rfc.xref.RFC6585.1">9.3</a>, <a href="#RFC6585"><b>11.2</b></a></li> 3756 3748 </ul> -
draft-ietf-httpbis/latest/p1-messaging.xml
r2569 r2580 50 50 <!ENTITY OPTIONS "<xref target='Part2' x:rel='#OPTIONS' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 51 51 <!ENTITY qvalue "<xref target='Part2' x:rel='#quality.values' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 52 <!ENTITY request-header-fields "<xref target='Part2' x:rel='#request.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 53 <!ENTITY response-control-data "<xref target='Part2' x:rel='#response.control.data' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 52 54 <!ENTITY resource "<xref target='Part2' x:rel='#resources' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 53 55 <!ENTITY semantics "<xref target='Part2' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 1972 1974 recipient to know when it has received the entire message. 1973 1975 </t> 1974 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="chunked-body"><!--terminal production--></iref><iref primary="true" item="Grammar" subitem="chunk"/><iref primary="true" item="Grammar" subitem="chunk-size"/><iref primary="true" item="Grammar" subitem="last-chunk"/><iref primary=" true" item="Grammar" subitem="chunk-ext"/><iref primary="true" item="Grammar" subitem="chunk-ext-name"/><iref primary="true" item="Grammar" subitem="chunk-ext-val"/><iref primary="true" item="Grammar" subitem="chunk-data"/><iref primary="false" item="Grammar" subitem="trailer-part"/>1976 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="chunked-body"><!--terminal production--></iref><iref primary="true" item="Grammar" subitem="chunk"/><iref primary="true" item="Grammar" subitem="chunk-size"/><iref primary="true" item="Grammar" subitem="last-chunk"/><iref primary="false" item="Grammar" subitem="trailer-part"/><iref primary="false" item="Grammar" subitem="chunk-ext"/><iref primary="true" item="Grammar" subitem="chunk-data"/> 1975 1977 <x:ref>chunked-body</x:ref> = *<x:ref>chunk</x:ref> 1976 1978 <x:ref>last-chunk</x:ref> … … 2005 2007 mid-message control information, or randomization of message body size. 2006 2008 </t> 2007 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="chunked-body"><!--terminal production--></iref><iref primary="true" item="Grammar" subitem="chunk "/><iref primary="true" item="Grammar" subitem="chunk-size"/><iref primary="true" item="Grammar" subitem="last-chunk"/><iref primary="true" item="Grammar" subitem="chunk-ext"/><iref primary="true" item="Grammar" subitem="chunk-ext-name"/><iref primary="true" item="Grammar" subitem="chunk-ext-val"/><iref primary="true" item="Grammar" subitem="chunk-data"/><iref primary="false" item="Grammar" subitem="trailer-part"/><iref primary="true" item="Grammar" subitem="quoted-str-nf"/><iref primary="true" item="Grammar" subitem="qdtext-nf"/>2009 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="chunked-body"><!--terminal production--></iref><iref primary="true" item="Grammar" subitem="chunk-ext"/><iref primary="true" item="Grammar" subitem="chunk-ext-name"/><iref primary="true" item="Grammar" subitem="chunk-ext-val"/> 2008 2010 <x:ref>chunk-ext</x:ref> = *( ";" <x:ref>chunk-ext-name</x:ref> [ "=" <x:ref>chunk-ext-val</x:ref> ] ) 2009 2011 … … 2040 2042 instead of the message's header section. 2041 2043 </t> 2042 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="trailer-part"/> 2044 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="trailer-part"/><iref primary="false" item="Grammar" subitem="header-field"/> 2043 2045 <x:ref>trailer-part</x:ref> = *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> ) 2044 2046 </artwork></figure> 2045 2047 <t> 2046 A sender &MUST-NOT; generate a trailer that contains a field which needs to 2047 be known by the recipient before it can begin processing the message body. 2048 For example, most recipients need to know the values of 2049 <x:ref>Content-Encoding</x:ref> and <x:ref>Content-Type</x:ref> in order to 2050 select a content handler, so placing those fields in a trailer would force 2051 the recipient to buffer the entire body before it could begin, greatly 2052 increasing user-perceived latency and defeating one of the main advantages 2053 of using chunked to send data streams of unknown length. 2054 A sender &MUST-NOT; generate a trailer containing a 2055 <x:ref>Transfer-Encoding</x:ref>, 2056 <x:ref>Content-Length</x:ref>, or 2057 <x:ref>Trailer</x:ref> field. 2058 </t> 2059 <t> 2060 A server &MUST; generate an empty trailer with the chunked transfer coding 2061 unless at least one of the following is true: 2062 <list style="numbers"> 2063 <t>the request included a <x:ref>TE</x:ref> header field that indicates 2064 "trailers" is acceptable in the transfer coding of the response, as 2065 described in <xref target="header.te"/>; or,</t> 2066 2067 <t>the trailer fields consist entirely of optional metadata and the 2068 recipient could use the message (in a manner acceptable to the generating 2069 server) without receiving that metadata. In other words, the generating 2070 server is willing to accept the possibility that the trailer fields might 2071 be silently discarded along the path to the client.</t> 2072 </list> 2073 </t> 2074 <t> 2075 The above requirement prevents the need for an infinite buffer when a 2076 message is being received by an HTTP/1.1 (or later) proxy and forwarded to 2077 an HTTP/1.0 recipient. 2048 A sender &MUST-NOT; generate a trailer that contains a field necessary for 2049 message framing (e.g., <x:ref>Transfer-Encoding</x:ref> and 2050 <x:ref>Content-Length</x:ref>), routing (e.g., <x:ref>Host</x:ref>), 2051 request modifiers (e.g., controls and conditionals in 2052 &request-header-fields;), authentication (e.g., see <xref target="Part7"/> 2053 and <xref target="RFC6265"/>), response control data (e.g., see 2054 &response-control-data;), or determining how to process the payload 2055 (e.g., <x:ref>Content-Encoding</x:ref>, <x:ref>Content-Type</x:ref>, 2056 <x:ref>Content-Range</x:ref>, and <x:ref>Trailer</x:ref>). 2057 </t> 2058 <t> 2059 When a chunked message containing a non-empty trailer is received, the 2060 recipient &MAY; process the fields (aside from those forbidden above) 2061 as if they were appended to the message's header section. 2062 A recipient &MUST; ignore (or consider as an error) any fields that are 2063 forbidden to be sent in a trailer, since processing them as if they were 2064 present in the header section might bypass external security filters. 2065 </t> 2066 <t> 2067 Unless the request includes a <x:ref>TE</x:ref> header field indicating 2068 "trailers" is acceptable, as described in <xref target="header.te"/>, a 2069 server &SHOULD-NOT; generate trailer fields that it believes are necessary 2070 for the user agent to receive. Without a TE containing "trailers", the 2071 server ought to assume that the trailer fields might be silently discarded 2072 along the path to the user agent. This requirement allows intermediaries to 2073 forward a de-chunked message to an HTTP/1.0 recipient without buffering the 2074 entire response. 2078 2075 </t> 2079 2076 </section> … … 2093 2090 read chunk-size, chunk-ext (if any), and CRLF 2094 2091 } 2095 read header-field 2096 while (header-field not empty) { 2097 append header-field to existing header fields 2098 read header-field 2092 read trailer field 2093 while (trailer field is not empty) { 2094 if trailer field is allowed to be sent in a trailer, 2095 append trailer field to existing header fields 2096 read trailer-field 2099 2097 } 2100 2098 Content-Length := length … … 2229 2227 to confirm an integrity check on the fly. 2230 2228 </t> 2231 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Trailer"/> 2229 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Trailer"/><iref primary="false" item="Grammar" subitem="field-name"/> 2232 2230 <x:ref>Trailer</x:ref> = 1#<x:ref>field-name</x:ref> 2233 2231 </artwork></figure> -
draft-ietf-httpbis/latest/p2-semantics.html
r2579 r2580 1223 1223 </tr> 1224 1224 <tr> 1225 <td class="left">Trailer</td> 1226 <td class="left"><a href="p1-messaging.html#header.trailer" title="Trailer">Section 4.4</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td> 1227 </tr> 1228 <tr> 1225 1229 <td class="left">Transfer-Encoding</td> 1226 <td class="left"><a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.1 4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td>1230 <td class="left"><a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td> 1227 1231 </tr> 1228 1232 </tbody> … … 1631 1635 <p id="rfc.section.4.3.6.p.2">CONNECT is intended only for use in requests to a proxy. An origin server that receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT. 1632 1636 </p> 1633 <p id="rfc.section.4.3.6.p.3">A client sending a CONNECT request <em class="bcp14">MUST</em> send the authority form of request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.1637 <p id="rfc.section.4.3.6.p.3">A client sending a CONNECT request <em class="bcp14">MUST</em> send the authority form of request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. 1634 1638 For example, 1635 1639 </p> … … 1670 1674 with a resource, or the capabilities of a server, without implying a resource action. 1671 1675 </p> 1672 <p id="rfc.section.4.3.7.p.2">An OPTIONS request with an asterisk ("*") as the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) applies to the server in general rather than to a specific resource. Since a server's communication options typically depend1676 <p id="rfc.section.4.3.7.p.2">An OPTIONS request with an asterisk ("*") as the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) applies to the server in general rather than to a specific resource. Since a server's communication options typically depend 1673 1677 on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the 1674 1678 client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 conformance (or … … 1693 1697 <h3 id="rfc.section.4.3.8"><a href="#rfc.section.4.3.8">4.3.8</a> <a href="#TRACE">TRACE</a></h3> 1694 1698 <div id="rfc.iref.t.1"></div> 1695 <p id="rfc.section.4.3.8.p.1">The TRACE method requests a remote, application-level loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received, excluding some fields described below, back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response with a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (<a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 8.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.1 7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The final recipient is either the origin server or the first server to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 5.1.2</a>).1699 <p id="rfc.section.4.3.8.p.1">The TRACE method requests a remote, application-level loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received, excluding some fields described below, back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response with a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (<a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 8.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The final recipient is either the origin server or the first server to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 5.1.2</a>). 1696 1700 </p> 1697 1701 <p id="rfc.section.4.3.8.p.2">A client <em class="bcp14">MUST NOT</em> generate header fields in a TRACE request containing sensitive data that might be disclosed by the response. For example, … … 1699 1703 </p> 1700 1704 <p id="rfc.section.4.3.8.p.3">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing 1701 or diagnostic information. The value of the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field (<a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.1 8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding1705 or diagnostic information. The value of the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field (<a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding 1702 1706 messages in an infinite loop. 1703 1707 </p> … … 1737 1741 <tr> 1738 1742 <td class="left">Host</td> 1739 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1. 19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td>1743 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td> 1740 1744 </tr> 1741 1745 <tr> … … 1753 1757 <tr> 1754 1758 <td class="left">TE</td> 1755 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 0"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td>1759 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td> 1756 1760 </tr> 1757 1761 </tbody> … … 1806 1810 </li> 1807 1811 <li>A server that responds with a final status code before reading the entire message body <em class="bcp14">SHOULD</em> indicate in that response whether it intends to close the connection or continue reading and discarding the request message 1808 (see <a href="p1-messaging.html#persistent.tear-down" title="Tear-down">Section 6.6</a> of <a href="#Part1" id="rfc.xref.Part1.2 1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).1812 (see <a href="p1-messaging.html#persistent.tear-down" title="Tear-down">Section 6.6</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 1809 1813 </li> 1810 1814 </ul> … … 2255 2259 </p> 2256 2260 <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.30"></span> <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#header.user-agent" class="smpl">product</a> *( <a href="#imported.abnf" class="smpl">RWS</a> ( <a href="#header.user-agent" class="smpl">product</a> / <a href="#imported.abnf" class="smpl">comment</a> ) ) 2257 </pre><p id="rfc.section.5.5.3.p.3">The User-Agent field-value consists of one or more product identifiers, each followed by zero or more comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.2 2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), which together identify the user agent software and its significant subproducts. By convention, the product identifiers2261 </pre><p id="rfc.section.5.5.3.p.3">The User-Agent field-value consists of one or more product identifiers, each followed by zero or more comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), which together identify the user agent software and its significant subproducts. By convention, the product identifiers 2258 2262 are listed in decreasing order of their significance for identifying the user agent software. Each product identifier consists 2259 2263 of a name and optional version. … … 2563 2567 <div id="rfc.iref.66"></div> 2564 2568 <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a> <a href="#status.101">101 Switching Protocols</a></h3> 2565 <p id="rfc.section.6.2.2.p.1">The <dfn>101 (Switching Protocols)</dfn> status code indicates that the server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.2 3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server <em class="bcp14">MUST</em> generate an Upgrade header field in the response that indicates which protocol(s) will be switched to immediately after the2569 <p id="rfc.section.6.2.2.p.1">The <dfn>101 (Switching Protocols)</dfn> status code indicates that the server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server <em class="bcp14">MUST</em> generate an Upgrade header field in the response that indicates which protocol(s) will be switched to immediately after the 2566 2570 empty line that terminates the 101 response. 2567 2571 </p> … … 2632 2636 <div id="rfc.iref.67"></div> 2633 2637 <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a> <a href="#status.203">203 Non-Authoritative Information</a></h3> 2634 <p id="rfc.section.6.3.4.p.1">The <dfn>203 (Non-Authoritative Information)</dfn> status code indicates that the request was successful but the enclosed payload has been modified from that of the origin server's <a href="#status.200" class="smpl">200 (OK)</a> response by a transforming proxy (<a href="p1-messaging.html#message.transformations" title="Transformations">Section 5.7.2</a> of <a href="#Part1" id="rfc.xref.Part1.2 4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). This status code allows the proxy to notify recipients when a transformation has been applied, since that knowledge might2638 <p id="rfc.section.6.3.4.p.1">The <dfn>203 (Non-Authoritative Information)</dfn> status code indicates that the request was successful but the enclosed payload has been modified from that of the origin server's <a href="#status.200" class="smpl">200 (OK)</a> response by a transforming proxy (<a href="p1-messaging.html#message.transformations" title="Transformations">Section 5.7.2</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). This status code allows the proxy to notify recipients when a transformation has been applied, since that knowledge might 2635 2639 impact later decisions regarding the content. For example, future cache validation requests for the content might only be 2636 2640 applicable along the same request path (through the same proxies). … … 2892 2896 <h3 id="rfc.section.6.5.7"><a href="#rfc.section.6.5.7">6.5.7</a> <a href="#status.408">408 Request Timeout</a></h3> 2893 2897 <p id="rfc.section.6.5.7.p.1">The <dfn>408 (Request Timeout)</dfn> status code indicates that the server did not receive a complete request message within the time that it was prepared to wait. 2894 A server <em class="bcp14">SHOULD</em> send the <a href="p1-messaging.html#header.connection" class="smpl">close</a> connection option (<a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.2 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) in the response, since 408 implies that the server has decided to close the connection rather than continue waiting. If2898 A server <em class="bcp14">SHOULD</em> send the <a href="p1-messaging.html#header.connection" class="smpl">close</a> connection option (<a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) in the response, since 408 implies that the server has decided to close the connection rather than continue waiting. If 2895 2899 the client has an outstanding request in transit, the client <em class="bcp14">MAY</em> repeat that request on a new connection. 2896 2900 </p> … … 2927 2931 <div id="rfc.iref.69"></div> 2928 2932 <h3 id="rfc.section.6.5.10"><a href="#rfc.section.6.5.10">6.5.10</a> <a href="#status.411">411 Length Required</a></h3> 2929 <p id="rfc.section.6.5.10.p.1">The <dfn>411 (Length Required)</dfn> status code indicates that the server refuses to accept the request without a defined <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> (<a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.2 6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request2933 <p id="rfc.section.6.5.10.p.1">The <dfn>411 (Length Required)</dfn> status code indicates that the server refuses to accept the request without a defined <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> (<a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request 2930 2934 message. 2931 2935 </p> … … 2943 2947 <div id="rfc.iref.69"></div> 2944 2948 <h3 id="rfc.section.6.5.12"><a href="#rfc.section.6.5.12">6.5.12</a> <a href="#status.414">414 URI Too Long</a></h3> 2945 <p id="rfc.section.6.5.12.p.1">The <dfn>414 (URI Too Long)</dfn> status code indicates that the server is refusing to service the request because the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly2949 <p id="rfc.section.6.5.12.p.1">The <dfn>414 (URI Too Long)</dfn> status code indicates that the server is refusing to service the request because the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly 2946 2950 converted a POST request to a GET request with long query information, when the client has descended into a "black hole" of 2947 2951 redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the server is under attack by a client … … 2969 2973 <h3 id="rfc.section.6.5.15"><a href="#rfc.section.6.5.15">6.5.15</a> <a href="#status.426">426 Upgrade Required</a></h3> 2970 2974 <p id="rfc.section.6.5.15.p.1">The <dfn>426 (Upgrade Required)</dfn> status code indicates that the server refuses to perform the request using the current protocol but might be willing to do 2971 so after the client upgrades to a different protocol. The server <em class="bcp14">MUST</em> send an <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field in a 426 response to indicate the required protocol(s) (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.2 8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).2975 so after the client upgrades to a different protocol. The server <em class="bcp14">MUST</em> send an <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field in a 426 response to indicate the required protocol(s) (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 2972 2976 </p> 2973 2977 <div id="rfc.figure.u.42"></div> … … 3036 3040 <p id="rfc.section.6.6.6.p.1">The <dfn>505 (HTTP Version Not Supported)</dfn> status code indicates that the server does not support, or refuses to support, the major version of HTTP that was used in 3037 3041 the request message. The server is indicating that it is unable or unwilling to complete the request using the same major 3038 version as the client, as described in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1. 29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, other than with this error message. The server <em class="bcp14">SHOULD</em> generate a representation for the 505 response that describes why that version is not supported and what other protocols are3042 version as the client, as described in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, other than with this error message. The server <em class="bcp14">SHOULD</em> generate a representation for the 505 response that describes why that version is not supported and what other protocols are 3039 3043 supported by that server. 3040 3044 </p> … … 3425 3429 </p> 3426 3430 <div id="rfc.figure.u.62"></div><pre class="inline"><span id="rfc.iref.g.55"></span> <a href="#header.server" class="smpl">Server</a> = <a href="#header.user-agent" class="smpl">product</a> *( <a href="#imported.abnf" class="smpl">RWS</a> ( <a href="#header.user-agent" class="smpl">product</a> / <a href="#imported.abnf" class="smpl">comment</a> ) ) 3427 </pre><p id="rfc.section.7.4.2.p.3">The Server field-value consists of one or more product identifiers, each followed by zero or more comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.3 0"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), which together identify the origin server software and its significant subproducts. By convention, the product identifiers3431 </pre><p id="rfc.section.7.4.2.p.3">The Server field-value consists of one or more product identifiers, each followed by zero or more comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), which together identify the origin server software and its significant subproducts. By convention, the product identifiers 3428 3432 are listed in decreasing order of their significance for identifying the origin server software. Each product identifier consists 3429 3433 of a name and optional version, as defined in <a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 5.5.3</a>. … … 3466 3470 to a single application or data format, since orthogonal technologies deserve orthogonal specification. 3467 3471 </p> 3468 <p id="rfc.section.8.1.2.p.2">Since message parsing (<a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) needs to be independent of method semantics (aside from responses to HEAD), definitions of new methods cannot change the3472 <p id="rfc.section.8.1.2.p.2">Since message parsing (<a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) needs to be independent of method semantics (aside from responses to HEAD), definitions of new methods cannot change the 3469 3473 parsing algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of 3470 3474 new methods can specify that only a zero-length message body is allowed by requiring a Content-Length header field with a … … 3847 3851 <h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a> <a href="#considerations.for.new.header.fields">Considerations for New Header Fields</a></h3> 3848 3852 <p id="rfc.section.8.3.1.p.1">Header fields are key:value pairs that can be used to communicate data about the message, its payload, the target resource, 3849 or the connection (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.3 2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for a general definition of header field syntax in HTTP messages.3853 or the connection (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for a general definition of header field syntax in HTTP messages. 3850 3854 </p> 3851 3855 <p id="rfc.section.8.3.1.p.2">The requirements for header field names are defined in <a href="#BCP90" id="rfc.xref.BCP90.2"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>. … … 3856 3860 processing, since the prefix would ensure that private names never collide with a newly registered Internet name; see <a href="#BCP178" id="rfc.xref.BCP178.1"><cite title="Deprecating the "X-" Prefix and Similar Constructs in Application Protocols">[BCP178]</cite></a> for further information) 3857 3861 </p> 3858 <p id="rfc.section.8.3.1.p.4">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Section 7</a> of <a href="#Part1" id="rfc.xref.Part1.3 3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters3862 <p id="rfc.section.8.3.1.p.4">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extension defined in <a href="p1-messaging.html#abnf.extension" title="ABNF list extension: #rule">Section 7</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters 3859 3863 can use an encoding such as the one defined in <a href="#RFC5987" id="rfc.xref.RFC5987.1"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>. 3860 3864 </p> 3861 <p id="rfc.section.8.3.1.p.5">Leading and trailing whitespace in raw field values is removed upon field parsing (<a href="p1-messaging.html#field.parsing" title="Field Parsing">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.3 4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). Field definitions where leading or trailing whitespace in values is significant will have to use a container syntax such3862 as quoted-string (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a> of <a href="#Part1" id="rfc.xref.Part1.3 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).3865 <p id="rfc.section.8.3.1.p.5">Leading and trailing whitespace in raw field values is removed upon field parsing (<a href="p1-messaging.html#field.parsing" title="Field Parsing">Section 3.2.4</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). Field definitions where leading or trailing whitespace in values is significant will have to use a container syntax such 3866 as quoted-string (<a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 3863 3867 </p> 3864 3868 <p id="rfc.section.8.3.1.p.6">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed … … 3882 3886 <ul> 3883 3887 <li> 3884 <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.3 6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).3888 <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 3885 3889 </p> 3886 3890 <p>If it does not use the list syntax, document how to treat messages where the field occurs multiple times (a sensible default … … 3905 3909 </li> 3906 3910 <li> 3907 <p>Whether it is appropriate to list the field-name in the <a href="p1-messaging.html#header.connection" class="smpl">Connection</a> header field (i.e., if the header field is to be hop-by-hop; see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.3 7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).3911 <p>Whether it is appropriate to list the field-name in the <a href="p1-messaging.html#header.connection" class="smpl">Connection</a> header field (i.e., if the header field is to be hop-by-hop; see <a href="p1-messaging.html#header.connection" title="Connection">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 3908 3912 </p> 3909 3913 </li> … … 3916 3920 </li> 3917 3921 <li> 3918 <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.3 8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).3922 <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 3919 3923 </p> 3920 3924 </li> … … 4090 4094 <div id="content.coding.registry"> 4091 4095 <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <a href="#content.coding.registry">Content Coding Registry</a></h2> 4092 <p id="rfc.section.8.4.p.1">The HTTP Content Coding Registry defines the name space for content coding names (<a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1. 39"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The content coding registry is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>.4096 <p id="rfc.section.8.4.p.1">The HTTP Content Coding Registry defines the name space for content coding names (<a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The content coding registry is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. 4093 4097 </p> 4094 4098 <div id="content.coding.procedure"> … … 4101 4105 <li>Pointer to specification text</li> 4102 4106 </ul> 4103 <p id="rfc.section.8.4.1.p.2">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.4 0"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).4107 <p id="rfc.section.8.4.1.p.2">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 4104 4108 </p> 4105 4109 <p id="rfc.section.8.4.1.p.3">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.3"><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 content coding defined in this section. … … 4137 4141 <p id="rfc.section.9.p.1">This section is meant to inform developers, information providers, and users of known security concerns relevant to HTTP semantics 4138 4142 and its use for transferring information over the Internet. Considerations related to message syntax, parsing, and routing 4139 are discussed in <a href="p1-messaging.html#security.considerations" title="Security Considerations">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.4 2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.4143 are discussed in <a href="p1-messaging.html#security.considerations" title="Security Considerations">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 4140 4144 </p> 4141 4145 <p id="rfc.section.9.p.2">The list of considerations below is not exhaustive. Most security concerns related to HTTP semantics are about securing server-side … … 4216 4220 <div id="disclosure.product.information"> 4217 4221 <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a> <a href="#disclosure.product.information">Disclosure of Product Information</a></h2> 4218 <p id="rfc.section.9.6.p.1">The <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section 5.5.3</a>), <a href="p1-messaging.html#header.via" class="smpl">Via</a> (<a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.4 3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), and <a href="#header.server" class="smpl">Server</a> (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 7.4.2</a>) header fields often reveal information about the respective sender's software systems. In theory, this can make it easier4222 <p id="rfc.section.9.6.p.1">The <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section 5.5.3</a>), <a href="p1-messaging.html#header.via" class="smpl">Via</a> (<a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), and <a href="#header.server" class="smpl">Server</a> (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 7.4.2</a>) header fields often reveal information about the respective sender's software systems. In theory, this can make it easier 4219 4223 for an attacker to exploit known security holes; in practice, attackers tend to try all potential holes regardless of the 4220 4224 apparent software versions being used. … … 4256 4260 <div id="acks"> 4257 4261 <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a href="#acks">Acknowledgments</a></h1> 4258 <p id="rfc.section.10.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 10</a> of <a href="#Part1" id="rfc.xref.Part1.4 4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.4262 <p id="rfc.section.10.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 10</a> of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 4259 4263 </p> 4260 4264 </div> … … 4551 4555 and the undesirable effect of potentially breaking relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section 3.1.4.2</a>) 4552 4556 </p> 4553 <p id="rfc.section.B.p.6">To be consistent with the method-neutral parsing algorithm of <a href="#Part1" id="rfc.xref.Part1.4 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, the definition of GET has been relaxed so that requests can have a body, even though a body has no meaning for GET. (<a href="#GET" id="rfc.xref.GET.6" title="GET">Section 4.3.1</a>)4557 <p id="rfc.section.B.p.6">To be consistent with the method-neutral parsing algorithm of <a href="#Part1" id="rfc.xref.Part1.46"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, the definition of GET has been relaxed so that requests can have a body, even though a body has no meaning for GET. (<a href="#GET" id="rfc.xref.GET.6" title="GET">Section 4.3.1</a>) 4554 4558 </p> 4555 4559 <p id="rfc.section.B.p.7">Servers are no longer required to handle all Content-* header fields and use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> has been explicitly banned in PUT requests. (<a href="#PUT" id="rfc.xref.PUT.5" title="PUT">Section 4.3.4</a>) … … 4612 4616 (any visible US-ASCII character). 4613 4617 </p> 4614 <p id="rfc.section.C.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.4 6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>:4615 </p> 4616 <div id="rfc.figure.u.65"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.4 7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>>4617 <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4 8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>>4618 <a href="#imported.abnf" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1. 49"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>>4619 <a href="#imported.abnf" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.5 0"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>4620 <a href="#imported.abnf" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.5 1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>4621 <a href="#imported.abnf" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.5 2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>>4622 <a href="#imported.abnf" class="smpl">field-name</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.5 3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>>4623 <a href="#imported.abnf" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.5 4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>4624 <a href="#imported.abnf" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.5 5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>>4625 <a href="#imported.abnf" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.5 6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>>4618 <p id="rfc.section.C.p.2">The rules below are defined in <a href="#Part1" id="rfc.xref.Part1.47"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>: 4619 </p> 4620 <div id="rfc.figure.u.65"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.48"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>> 4621 <a href="#imported.abnf" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.49"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>> 4622 <a href="#imported.abnf" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1.50"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#whitespace" title="Whitespace">Section 3.2.3</a>> 4623 <a href="#imported.abnf" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.51"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 4624 <a href="#imported.abnf" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.52"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 4625 <a href="#imported.abnf" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.53"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>> 4626 <a href="#imported.abnf" class="smpl">field-name</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.54"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>> 4627 <a href="#imported.abnf" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.55"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 4628 <a href="#imported.abnf" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.56"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>> 4629 <a href="#imported.abnf" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.57"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>> 4626 4630 </pre></div> 4627 4631 <div id="collected.abnf"> 4628 4632 <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a> <a href="#collected.abnf">Collected ABNF</a></h1> 4629 <p id="rfc.section.D.p.1">In the collected ABNF below, list rules are expanded as per <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.5 7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.4633 <p id="rfc.section.D.p.1">In the collected ABNF below, list rules are expanded as per <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.58"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 4630 4634 </p> 4631 4635 <div id="rfc.figure.u.66"></div><pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ … … 4989 4993 </li> 4990 4994 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 4991 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.14">3.3</a>, <a href="#rfc.xref.Part1.15"> 4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.19">5.1</a>, <a href="#rfc.xref.Part1.20">5.1</a>, <a href="#rfc.xref.Part1.21">5.1.1</a>, <a href="#rfc.xref.Part1.22">5.5.3</a>, <a href="#rfc.xref.Part1.23">6.2.2</a>, <a href="#rfc.xref.Part1.24">6.3.4</a>, <a href="#rfc.xref.Part1.25">6.5.7</a>, <a href="#rfc.xref.Part1.26">6.5.10</a>, <a href="#rfc.xref.Part1.27">6.5.12</a>, <a href="#rfc.xref.Part1.28">6.5.15</a>, <a href="#rfc.xref.Part1.29">6.6.6</a>, <a href="#rfc.xref.Part1.30">7.4.2</a>, <a href="#rfc.xref.Part1.31">8.1.2</a>, <a href="#rfc.xref.Part1.32">8.3.1</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.35">8.3.1</a>, <a href="#rfc.xref.Part1.36">8.3.1</a>, <a href="#rfc.xref.Part1.37">8.3.1</a>, <a href="#rfc.xref.Part1.38">8.3.1</a>, <a href="#rfc.xref.Part1.39">8.4</a>, <a href="#rfc.xref.Part1.40">8.4.1</a>, <a href="#rfc.xref.Part1.41">8.4.1</a>, <a href="#rfc.xref.Part1.42">9</a>, <a href="#rfc.xref.Part1.43">9.6</a>, <a href="#rfc.xref.Part1.44">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.45">B</a>, <a href="#rfc.xref.Part1.46">C</a>, <a href="#rfc.xref.Part1.47">C</a>, <a href="#rfc.xref.Part1.48">C</a>, <a href="#rfc.xref.Part1.49">C</a>, <a href="#rfc.xref.Part1.50">C</a>, <a href="#rfc.xref.Part1.51">C</a>, <a href="#rfc.xref.Part1.52">C</a>, <a href="#rfc.xref.Part1.53">C</a>, <a href="#rfc.xref.Part1.54">C</a>, <a href="#rfc.xref.Part1.55">C</a>, <a href="#rfc.xref.Part1.56">C</a>, <a href="#rfc.xref.Part1.57">D</a><ul>4992 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.5 7">D</a></li>4995 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.14">3.3</a>, <a href="#rfc.xref.Part1.15">3.3</a>, <a href="#rfc.xref.Part1.16">4.3.6</a>, <a href="#rfc.xref.Part1.17">4.3.7</a>, <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.19">4.3.8</a>, <a href="#rfc.xref.Part1.20">5.1</a>, <a href="#rfc.xref.Part1.21">5.1</a>, <a href="#rfc.xref.Part1.22">5.1.1</a>, <a href="#rfc.xref.Part1.23">5.5.3</a>, <a href="#rfc.xref.Part1.24">6.2.2</a>, <a href="#rfc.xref.Part1.25">6.3.4</a>, <a href="#rfc.xref.Part1.26">6.5.7</a>, <a href="#rfc.xref.Part1.27">6.5.10</a>, <a href="#rfc.xref.Part1.28">6.5.12</a>, <a href="#rfc.xref.Part1.29">6.5.15</a>, <a href="#rfc.xref.Part1.30">6.6.6</a>, <a href="#rfc.xref.Part1.31">7.4.2</a>, <a href="#rfc.xref.Part1.32">8.1.2</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.35">8.3.1</a>, <a href="#rfc.xref.Part1.36">8.3.1</a>, <a href="#rfc.xref.Part1.37">8.3.1</a>, <a href="#rfc.xref.Part1.38">8.3.1</a>, <a href="#rfc.xref.Part1.39">8.3.1</a>, <a href="#rfc.xref.Part1.40">8.4</a>, <a href="#rfc.xref.Part1.41">8.4.1</a>, <a href="#rfc.xref.Part1.42">8.4.1</a>, <a href="#rfc.xref.Part1.43">9</a>, <a href="#rfc.xref.Part1.44">9.6</a>, <a href="#rfc.xref.Part1.45">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.46">B</a>, <a href="#rfc.xref.Part1.47">C</a>, <a href="#rfc.xref.Part1.48">C</a>, <a href="#rfc.xref.Part1.49">C</a>, <a href="#rfc.xref.Part1.50">C</a>, <a href="#rfc.xref.Part1.51">C</a>, <a href="#rfc.xref.Part1.52">C</a>, <a href="#rfc.xref.Part1.53">C</a>, <a href="#rfc.xref.Part1.54">C</a>, <a href="#rfc.xref.Part1.55">C</a>, <a href="#rfc.xref.Part1.56">C</a>, <a href="#rfc.xref.Part1.57">C</a>, <a href="#rfc.xref.Part1.58">D</a><ul> 4996 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.58">D</a></li> 4993 4997 <li><em>Section 2.5</em> <a href="#rfc.xref.Part1.2">1.1</a></li> 4994 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1. 29">6.6.6</a></li>4995 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5 0">C</a>, <a href="#rfc.xref.Part1.51">C</a>, <a href="#rfc.xref.Part1.54">C</a></li>4996 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.2 2">5.5.3</a>, <a href="#rfc.xref.Part1.30">7.4.2</a>, <a href="#rfc.xref.Part1.32">8.3.1</a>, <a href="#rfc.xref.Part1.36">8.3.1</a>, <a href="#rfc.xref.Part1.53">C</a></li>4997 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.4 7">C</a>, <a href="#rfc.xref.Part1.48">C</a>, <a href="#rfc.xref.Part1.49">C</a></li>4998 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.3 4">8.3.1</a></li>4999 <li><em>Section 3.2.6</em> <a href="#rfc.xref.Part1.3 5">8.3.1</a>, <a href="#rfc.xref.Part1.52">C</a>, <a href="#rfc.xref.Part1.55">C</a>, <a href="#rfc.xref.Part1.56">C</a></li>5000 <li><em>Section 3.3.1</em> <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.1 4">3.3</a></li>5001 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.3 1">8.1.2</a></li>5002 <li><em>Section 3.3.2</em> <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.2 6">6.5.10</a></li>5003 <li><em>Section 4</em> <a href="#rfc.xref.Part1.4 0">8.4.1</a></li>5004 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.3 8">8.3.1</a></li>4998 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.30">6.6.6</a></li> 4999 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.51">C</a>, <a href="#rfc.xref.Part1.52">C</a>, <a href="#rfc.xref.Part1.55">C</a></li> 5000 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.23">5.5.3</a>, <a href="#rfc.xref.Part1.31">7.4.2</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.37">8.3.1</a>, <a href="#rfc.xref.Part1.54">C</a></li> 5001 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.48">C</a>, <a href="#rfc.xref.Part1.49">C</a>, <a href="#rfc.xref.Part1.50">C</a></li> 5002 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.35">8.3.1</a></li> 5003 <li><em>Section 3.2.6</em> <a href="#rfc.xref.Part1.36">8.3.1</a>, <a href="#rfc.xref.Part1.53">C</a>, <a href="#rfc.xref.Part1.56">C</a>, <a href="#rfc.xref.Part1.57">C</a></li> 5004 <li><em>Section 3.3.1</em> <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.15">3.3</a></li> 5005 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.32">8.1.2</a></li> 5006 <li><em>Section 3.3.2</em> <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.27">6.5.10</a></li> 5007 <li><em>Section 4</em> <a href="#rfc.xref.Part1.41">8.4.1</a></li> 5008 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.39">8.3.1</a></li> 5005 5009 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part1.7">3.1.2.1</a></li> 5006 <li><em>Section 4.2</em> <a href="#rfc.xref.Part1. 39">8.4</a>, <a href="#rfc.xref.Part1.41">8.4.1</a></li>5010 <li><em>Section 4.2</em> <a href="#rfc.xref.Part1.40">8.4</a>, <a href="#rfc.xref.Part1.42">8.4.1</a></li> 5007 5011 <li><em>Section 4.2.2</em> <a href="#rfc.xref.Part1.8">3.1.2.1</a></li> 5008 5012 <li><em>Section 4.2.3</em> <a href="#rfc.xref.Part1.9">3.1.2.1</a></li> 5009 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.20">5.1</a></li> 5010 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.27">6.5.12</a></li> 5011 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.19">5.1</a></li> 5013 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.21">5.1</a></li> 5014 <li><em>Section 4.4</em> <a href="#rfc.xref.Part1.14">3.3</a></li> 5015 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.16">4.3.6</a>, <a href="#rfc.xref.Part1.17">4.3.7</a>, <a href="#rfc.xref.Part1.28">6.5.12</a></li> 5016 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.20">5.1</a></li> 5012 5017 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a></li> 5013 <li><em>Section 5.7.1</em> <a href="#rfc.xref.Part1.1 8">4.3.8</a>, <a href="#rfc.xref.Part1.43">9.6</a></li>5014 <li><em>Section 5.7.2</em> <a href="#rfc.xref.Part1.2 4">6.3.4</a></li>5015 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.2 5">6.5.7</a>, <a href="#rfc.xref.Part1.37">8.3.1</a></li>5016 <li><em>Section 6.6</em> <a href="#rfc.xref.Part1.2 1">5.1.1</a></li>5017 <li><em>Section 6.7</em> <a href="#rfc.xref.Part1.2 3">6.2.2</a>, <a href="#rfc.xref.Part1.28">6.5.15</a></li>5018 <li><em>Section 7</em> <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.3 3">8.3.1</a></li>5019 <li><em>Section 8.3.1</em> <a href="#rfc.xref.Part1.1 7">4.3.8</a></li>5020 <li><em>Section 9</em> <a href="#rfc.xref.Part1.4 2">9</a></li>5021 <li><em>Section 10</em> <a href="#rfc.xref.Part1.4 4">10</a></li>5018 <li><em>Section 5.7.1</em> <a href="#rfc.xref.Part1.19">4.3.8</a>, <a href="#rfc.xref.Part1.44">9.6</a></li> 5019 <li><em>Section 5.7.2</em> <a href="#rfc.xref.Part1.25">6.3.4</a></li> 5020 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.26">6.5.7</a>, <a href="#rfc.xref.Part1.38">8.3.1</a></li> 5021 <li><em>Section 6.6</em> <a href="#rfc.xref.Part1.22">5.1.1</a></li> 5022 <li><em>Section 6.7</em> <a href="#rfc.xref.Part1.24">6.2.2</a>, <a href="#rfc.xref.Part1.29">6.5.15</a></li> 5023 <li><em>Section 7</em> <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.34">8.3.1</a></li> 5024 <li><em>Section 8.3.1</em> <a href="#rfc.xref.Part1.18">4.3.8</a></li> 5025 <li><em>Section 9</em> <a href="#rfc.xref.Part1.43">9</a></li> 5026 <li><em>Section 10</em> <a href="#rfc.xref.Part1.45">10</a></li> 5022 5027 </ul> 5023 5028 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2579 r2580 68 68 <!ENTITY header-range "<xref target='Part5' x:rel='#header.range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 69 69 <!ENTITY header-te "<xref target='Part1' x:rel='#header.te' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 70 <!ENTITY header-trailer "<xref target='Part1' x:rel='#header.trailer' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 70 71 <!ENTITY header-transfer-encoding "<xref target='Part1' x:rel='#header.transfer-encoding' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 71 72 <!ENTITY header-upgrade "<xref target='Part1' x:rel='#header.upgrade' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 920 921 <c>Content-Length</c> <c>&header-content-length;</c> 921 922 <c>Content-Range</c> <c>&header-content-range;</c> 923 <c>Trailer</c> <c>&header-trailer;</c> 922 924 <c>Transfer-Encoding</c> <c>&header-transfer-encoding;</c> 923 925 </texttable>
Note: See TracChangeset
for help on using the changeset viewer.