![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 1859 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 03/09/12 22:12:40 (9 years ago)
- File:
-
- 1 edited
-
draft-ietf-httpbis/latest/p1-messaging.html (modified) (35 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1845 r1859 449 449 } 450 450 @bottom-center { 451 content: "Expires March 5, 2013";451 content: "Expires March 7, 2013"; 452 452 } 453 453 @bottom-right { … … 492 492 <meta name="dct.creator" content="Reschke, J. F."> 493 493 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 494 <meta name="dct.issued" scheme="ISO8601" content="2012-09-0 1">494 <meta name="dct.issued" scheme="ISO8601" content="2012-09-03"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 496 496 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 524 524 </tr> 525 525 <tr> 526 <td class="left">Expires: March 5, 2013</td>526 <td class="left">Expires: March 7, 2013</td> 527 527 <td class="right">greenbytes</td> 528 528 </tr> 529 529 <tr> 530 530 <td class="left"></td> 531 <td class="right">September 1, 2012</td>531 <td class="right">September 3, 2012</td> 532 532 </tr> 533 533 </tbody> … … 556 556 in progress”. 557 557 </p> 558 <p>This Internet-Draft will expire on March 5, 2013.</p>558 <p>This Internet-Draft will expire on March 7, 2013.</p> 559 559 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 560 560 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 658 658 </ul> 659 659 </li> 660 <li><a href="#rfc.section.6.3">6.3</a> <a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li> 661 <li><a href="#rfc.section.6.4">6.4</a> <a href="#header.upgrade">Upgrade</a></li> 660 <li><a href="#rfc.section.6.3">6.3</a> <a href="#header.upgrade">Upgrade</a></li> 662 661 </ul> 663 662 </li> … … 908 907 or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization) 909 908 that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform 910 a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 5.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 7.6</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations.909 a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 7.3.4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 7.6</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations. 911 910 </p> 912 911 <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.13"></span><span id="rfc.iref.r.4"></span> <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying … … 1078 1077 </p> 1079 1078 <p id="rfc.section.2.7.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port, 1080 and sending an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 5</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.1079 and sending an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 7</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request. 1081 1080 </p> 1082 1081 <p id="rfc.section.2.7.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name … … 1176 1175 </div> 1177 1176 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.29"></span> <a href="#method" class="smpl">method</a> = <a href="#rule.token.separators" class="smpl">token</a> 1178 </pre><p id="rfc.section.3.1.1.p.6">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 3</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.1177 </pre><p id="rfc.section.3.1.1.p.6">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 5</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods. 1179 1178 </p> 1180 1179 <div id="rfc.iref.r.6"></div> … … 1189 1188 </p> 1190 1189 <p id="rfc.section.3.1.1.p.10">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that 1191 it implements <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.405" class="smpl">405 (Method Not Allowed)</a>, if it is an origin server, or a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 5.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>).1190 it implements <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.405" class="smpl">405 (Method Not Allowed)</a>, if it is an origin server, or a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 7.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). 1192 1191 </p> 1193 1192 <p id="rfc.section.3.1.1.p.11">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of up to 8000 octets. … … 1202 1201 <p id="rfc.section.3.1.2.p.4">The status-code element is a 3-digit integer code describing the result of the server's attempt to understand and satisfy 1203 1202 the client's corresponding request. The rest of the response message is to be interpreted in light of the semantics defined 1204 for that status code. See <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 5</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> for information about the semantics of status codes, including the classes of status code (indicated by the first digit),1203 for that status code. See <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 7</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> for information about the semantics of status codes, including the classes of status code (indicated by the first digit), 1205 1204 the status codes defined by this specification, considerations for the definition of new status codes, and the IANA registry. 1206 1205 </p> … … 1223 1222 ; see <a href="#field.parsing" title="Field Parsing">Section 3.2.2</a> 1224 1223 </pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example, 1225 the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 10.10</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.1224 the <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 8.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears. 1226 1225 </p> 1227 1226 <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining … … 1231 1230 them. 1232 1231 </p> 1233 <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for. creating.header.fields" title="Considerations for Creating Header Fields">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.1232 <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.new.header.fields" title="Considerations for New Header Fields">Section 10.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients. 1234 1233 </p> 1235 1234 <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice" … … 1383 1382 <p id="rfc.section.3.3.1.p.6">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section 3.2</a>, before determining the message body length. 1384 1383 </p> 1385 <p id="rfc.section.3.3.1.p.7">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.1384 <p id="rfc.section.3.3.1.p.7">Unlike <a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 9.4</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. 1386 1385 </p> 1387 1386 <p id="rfc.section.3.3.1.p.8">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer … … 1663 1662 that a client can be assured of buffering the entire response. 1664 1663 </p> 1665 <p id="rfc.section.4.3.p.7">When multiple transfer-codings are acceptable, the client <em class="bcp14">MAY</em> rank the codings by preference using a "q" parameter (similar to the qvalues used in content negotiation fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 9.3</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred;1664 <p id="rfc.section.4.3.p.7">When multiple transfer-codings are acceptable, the client <em class="bcp14">MAY</em> rank the codings by preference using a "q" parameter (similar to the qvalues used in content negotiation fields, <a href="p2-semantics.html#quality.values" title="Quality Values">Section 6.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). The rank value is a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred; 1666 1665 a value of 0 means "not acceptable". 1667 1666 </p> … … 1743 1742 </p> 1744 1743 <div id="authority-form"> 1745 <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 3.3.8</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[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) as the request-target. For example,1744 <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 5.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[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) as the request-target. For example, 1746 1745 </p> 1747 1746 </div> 1748 1747 <div id="rfc.figure.u.41"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1 1749 1748 </pre><div id="asterisk-form"> 1750 <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 3.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,1749 <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 5.3.7</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server, 1751 1750 the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example, 1752 1751 </p> … … 1894 1893 </p> 1895 1894 <ul> 1896 <li><a href="p2-semantics.html#header.allow" class="smpl">Allow</a> (<a href="p2-semantics.html#header.allow" title="Allow">Section 10.5</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>)1897 </li> 1898 <li><a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> (<a href="p2-semantics.html#header.content-location" title="Content-Location">Section 10.8</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>)1895 <li><a href="p2-semantics.html#header.allow" class="smpl">Allow</a> (<a href="p2-semantics.html#header.allow" title="Allow">Section 8.4.1</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) 1896 </li> 1897 <li><a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> (<a href="p2-semantics.html#header.content-location" title="Content-Location">Section 3.2.4</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) 1899 1898 </li> 1900 1899 <li>Content-MD5 (<a href="http://tools.ietf.org/html/rfc2616#section-14.15">Section 14.15</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) … … 1904 1903 <li><a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) 1905 1904 </li> 1906 <li><a href="p2-semantics.html#header.server" class="smpl">Server</a> (<a href="p2-semantics.html#header.server" title="Server">Section 10.17</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>)1905 <li><a href="p2-semantics.html#header.server" class="smpl">Server</a> (<a href="p2-semantics.html#header.server" title="Server">Section 8.4.2</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) 1907 1906 </li> 1908 1907 </ul> … … 1912 1911 </p> 1913 1912 <ul> 1914 <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 10.6</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>)1913 <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 3.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) 1915 1914 </li> 1916 1915 <li><a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests">[Part5]</cite></a>) 1917 1916 </li> 1918 <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 10.9</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>)1917 <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 3.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) 1919 1918 </li> 1920 1919 </ul> … … 1929 1928 <p id="rfc.section.5.9.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response 1930 1929 messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made 1931 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 5.2</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) precede a final response to the same request.1930 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 7.2</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) precede a final response to the same request. 1932 1931 </p> 1933 1932 <p id="rfc.section.5.9.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response. … … 2038 2037 <p id="rfc.section.6.2.2.1.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. 2039 2038 </p> 2040 <p id="rfc.section.6.2.2.1.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 3.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to2039 <p id="rfc.section.6.2.2.1.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 2041 2040 send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request. 2042 2041 </p> 2043 2042 <h4 id="rfc.section.6.2.2.2"><a href="#rfc.section.6.2.2.2">6.2.2.2</a> <a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h4> 2044 2043 <p id="rfc.section.6.2.2.2.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request 2045 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 3.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding2044 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 5.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding 2046 2045 of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails. 2047 2046 </p> … … 2093 2092 by the HTTP application. 2094 2093 </p> 2095 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h2>2096 <p id="rfc.section.6.3.p.1">The purpose of the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 5.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing2097 to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might2098 either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without2099 looking at the body.2100 </p>2101 <p id="rfc.section.6.3.p.2">Requirements for HTTP/1.1 clients: </p>2102 <ul>2103 <li>If a client will wait for a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 10.11</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) with the "100-continue" expectation.2104 </li>2105 <li>A client <em class="bcp14">MUST NOT</em> send an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation if it does not intend to send a request body.2106 </li>2107 </ul>2108 <p id="rfc.section.6.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:2109 100-continue" without receiving either a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> or a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has2110 never seen a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body.2111 </p>2112 <p id="rfc.section.6.3.p.4">Requirements for HTTP/1.1 origin servers: </p>2113 <ul>2114 <li>Upon receiving a request which includes an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code.2115 </li>2116 <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility2117 with <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code in response to an HTTP/1.1 PUT or POST request that does not include an Expect header field with the "100-continue"2118 expectation. This exception, the purpose of which is to minimize any client processing delays associated with an undeclared2119 wait for <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> status code, applies only to HTTP/1.1 requests, and not to requests with any other HTTP-version value.2120 </li>2121 <li>An origin server <em class="bcp14">MAY</em> omit a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if it has already received some or all of the request body for the corresponding request.2122 </li>2123 <li>An origin server that sends a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response <em class="bcp14">MUST</em> ultimately send a final status code, once the request body is received and processed, unless it terminates the transport connection2124 prematurely.2125 </li>2126 <li>If an origin server receives a request that does not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, the request includes a request body, and the server responds with a final2127 status code before reading the entire request body from the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise,2128 the client might not reliably receive the response message. However, this requirement ought not be construed as preventing2129 a server from defending itself against denial-of-service attacks, or from badly broken client implementations.2130 </li>2131 </ul>2132 <p id="rfc.section.6.3.p.5">Requirements for HTTP/1.1 proxies: </p>2133 <ul>2134 <li>If a proxy receives a request that includes an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and the proxy either knows that the next-hop server complies with HTTP/1.12135 or higher, or does not know the HTTP version of the next-hop server, it <em class="bcp14">MUST</em> forward the request, including the Expect header field.2136 </li>2137 <li>If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it <em class="bcp14">MUST NOT</em> forward the request, and it <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> status code.2138 </li>2139 <li>Proxies <em class="bcp14">SHOULD</em> maintain a record of the HTTP version numbers received from recently-referenced next-hop servers.2140 </li>2141 <li>A proxy <em class="bcp14">MUST NOT</em> forward a <a href="p2-semantics.html#status.100" class="smpl">100 (Continue)</a> response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an <a href="p2-semantics.html#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of <a href="p2-semantics.html#status.1xx" class="smpl">1xx</a> responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 5.2</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>).2142 </li>2143 </ul>2144 2094 <div id="rfc.iref.u.5"></div> 2145 2095 <div id="rfc.iref.h.14"></div> 2146 <h2 id="rfc.section.6. 4"><a href="#rfc.section.6.4">6.4</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2>2147 <p id="rfc.section.6. 4.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the2096 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2> 2097 <p id="rfc.section.6.3.p.1">The "Upgrade" header field allows the client to specify what additional communication protocols it would like to use, if the 2148 2098 server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to. 2149 2099 </p> … … 2153 2103 <a href="#header.upgrade" class="smpl">protocol-name</a> = <a href="#rule.token.separators" class="smpl">token</a> 2154 2104 <a href="#header.upgrade" class="smpl">protocol-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 2155 </pre><p id="rfc.section.6. 4.p.3">For example,</p>2105 </pre><p id="rfc.section.6.3.p.3">For example,</p> 2156 2106 <div id="rfc.figure.u.58"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2157 </pre><p id="rfc.section.6. 4.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible2107 </pre><p id="rfc.section.6.3.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible 2158 2108 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP 2159 2109 with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult … … 2162 2112 the server, possibly according to the nature of the request method or target resource). 2163 2113 </p> 2164 <p id="rfc.section.6. 4.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection.2114 <p id="rfc.section.6.3.p.6">The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection. 2165 2115 Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities 2166 2116 and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen, 2167 2117 although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request containing the Upgrade header field. 2168 2118 </p> 2169 <p id="rfc.section.6. 4.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 6.1</a>) whenever Upgrade is present in an HTTP/1.1 message.2170 </p> 2171 <p id="rfc.section.6. 4.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it2172 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 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>).2173 </p> 2174 <p id="rfc.section.6. 4.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in <a href="p2-semantics.html#status.101" class="smpl">101 (Switching2119 <p id="rfc.section.6.3.p.7">The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword <em class="bcp14">MUST</em> be supplied within a <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.7" title="Connection">Section 6.1</a>) whenever Upgrade is present in an HTTP/1.1 message. 2120 </p> 2121 <p id="rfc.section.6.3.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it 2122 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 7.4</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). 2123 </p> 2124 <p id="rfc.section.6.3.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in <a href="p2-semantics.html#status.101" class="smpl">101 (Switching 2175 2125 Protocols)</a> responses to indicate which protocol(s) are being switched to, and <em class="bcp14">MUST</em> include it in <a href="p2-semantics.html#status.426" class="smpl">426 (Upgrade Required)</a> responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols. 2176 2126 </p> 2177 <p id="rfc.section.6. 4.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined2127 <p id="rfc.section.6.3.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined 2178 2128 by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section 2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined 2179 2129 in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 7.6</a>. … … 2244 2194 <td class="left">http</td> 2245 2195 <td class="left">standard</td> 2246 <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 6. 4</a>2196 <td class="left"> <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section 6.3</a> 2247 2197 </td> 2248 2198 </tr> … … 2434 2384 <li>Pointer to specification text</li> 2435 2385 </ul> 2436 <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.28"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>.2386 <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 9.4</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>. 2437 2387 </p> 2438 2388 <p id="rfc.section.7.4.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section. Use of program names for the identification of encoding … … 2590 2540 that most implementations will choose substantially higher limits. 2591 2541 </p> 2592 <p id="rfc.section.8.6.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 5.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.29"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 5.5</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>).2542 <p id="rfc.section.8.6.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 7.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 7.5</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="HTTP/1.1, part 2: Semantics and Payloads">[Part2]</cite></a>). 2593 2543 </p> 2594 2544 <p id="rfc.section.8.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability. 2595 2545 </p> 2596 2546 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 2597 <p id="rfc.section.9.p.1">This edition of HTTP builds on the many contributions that went into <a href="#RFC1945" id="rfc.xref.RFC1945.2">RFC 1945</a>, <a href="#RFC2068" id="rfc.xref.RFC2068. 5">RFC 2068</a>, <a href="#RFC2145" id="rfc.xref.RFC2145.2">RFC 2145</a>, and <a href="#RFC2616" id="rfc.xref.RFC2616.4">RFC 2616</a>, including substantial contributions made by the previous authors, editors, and working group chairs: Tim Berners-Lee, Ari2547 <p id="rfc.section.9.p.1">This edition of HTTP builds on the many contributions that went into <a href="#RFC1945" id="rfc.xref.RFC1945.2">RFC 1945</a>, <a href="#RFC2068" id="rfc.xref.RFC2068.4">RFC 2068</a>, <a href="#RFC2145" id="rfc.xref.RFC2145.2">RFC 2145</a>, and <a href="#RFC2616" id="rfc.xref.RFC2616.4">RFC 2616</a>, including substantial contributions made by the previous authors, editors, and working group chairs: Tim Berners-Lee, Ari 2598 2548 Luotonen, Roy T. Fielding, Henrik Frystyk Nielsen, Jim Gettys, Jeffrey C. Mogul, Larry Masinter, Paul J. Leach, and Mark Nottingham. 2599 2549 See <a href="http://tools.ietf.org/html/rfc2616#section-16">Section 16</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> for additional acknowledgements from prior revisions. … … 2854 2804 <p id="rfc.section.A.1.2.p.1">In HTTP/1.0, each connection is established by the client prior to the request and closed by the server after sending the 2855 2805 response. However, some implementations implement the explicitly negotiated ("Keep-Alive") version of persistent connections 2856 described in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068. 6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.2806 described in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. 2857 2807 </p> 2858 2808 <p id="rfc.section.A.1.2.p.2">Some clients and servers might wish to be compatible with these previous approaches to persistent connections, by explicitly … … 2908 2858 <p id="rfc.section.A.2.p.14">Clarify exactly when "close" connection options have to be sent. (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section 6.1</a>) 2909 2859 </p> 2910 <p id="rfc.section.A.2.p.15">Define the semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section 6. 4</a>)2860 <p id="rfc.section.A.2.p.15">Define the semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section 6.3</a>) 2911 2861 </p> 2912 2862 <p id="rfc.section.A.2.p.16">Take over the Upgrade Token Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 7.6</a>) … … 3497 3447 <li>compress (Coding Format) <a href="#rfc.iref.c.9">4.2.1</a></li> 3498 3448 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></a></li> 3499 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6. 4</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li>3449 <li>Connection header field <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.c.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li> 3500 3450 <li>Content-Length header field <a href="#rfc.iref.c.6"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a></li> 3501 3451 </ul> … … 3598 3548 <li><tt>transfer-extension</tt> <a href="#rfc.iref.g.56"><b>4</b></a></li> 3599 3549 <li><tt>transfer-parameter</tt> <a href="#rfc.iref.g.57"><b>4</b></a></li> 3600 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.93"><b>6. 4</b></a></li>3550 <li><tt>Upgrade</tt> <a href="#rfc.iref.g.93"><b>6.3</b></a></li> 3601 3551 <li><tt>uri-host</tt> <a href="#rfc.iref.g.22"><b>2.7</b></a></li> 3602 3552 <li><tt>URI-reference</tt> <a href="#rfc.iref.g.16"><b>2.7</b></a></li> … … 3614 3564 <li>Header Fields 3615 3565 <ul> 3616 <li>Connection <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.h.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6. 4</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li>3566 <li>Connection <a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.iref.h.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.6">6.2.5</a>, <a href="#rfc.xref.header.connection.7">6.3</a>, <a href="#rfc.xref.header.connection.8">7.1</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">A.2</a></li> 3617 3567 <li>Content-Length <a href="#rfc.iref.h.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a></li> 3618 3568 <li>Host <a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.iref.h.11"><b>5.4</b></a>, <a href="#rfc.xref.header.host.2">7.1</a>, <a href="#rfc.xref.header.host.3">A.1.1</a></li> … … 3620 3570 <li>Trailer <a href="#rfc.iref.h.8"><b>4.1.1</b></a>, <a href="#rfc.xref.header.trailer.1">7.1</a></li> 3621 3571 <li>Transfer-Encoding <a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.h.6"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">4</a>, <a href="#rfc.xref.header.transfer-encoding.3">7.1</a>, <a href="#rfc.xref.header.transfer-encoding.4">A.1.3</a></li> 3622 <li>Upgrade <a href="#rfc.iref.h.14"><b>6. 4</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li>3572 <li>Upgrade <a href="#rfc.iref.h.14"><b>6.3</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li> 3623 3573 <li>Via <a href="#rfc.xref.header.via.1">2.3</a>, <a href="#rfc.iref.h.12"><b>5.7</b></a>, <a href="#rfc.xref.header.via.2">7.1</a></li> 3624 3574 </ul> … … 3665 3615 </li> 3666 3616 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3667 <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.3</a>, <a href="#rfc.xref.Part2.4">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5.8</a>, <a href="#rfc.xref.Part2.16">5.8</a>, <a href="#rfc.xref.Part2.17">5.8</a>, <a href="#rfc.xref.Part2.18">5.8</a>, <a href="#rfc.xref.Part2.19">5.8</a>, <a href="#rfc.xref.Part2.20">5.8</a>, <a href="#rfc.xref.Part2.21">5.9</a>, <a href="#rfc.xref.Part2.22">6.2.2.1</a>, <a href="#rfc.xref.Part2.23">6.2.2.2</a>, <a href="#rfc.xref.Part2.24">6.3</a>, <a href="#rfc.xref.Part2.25">6.3</a>, <a href="#rfc.xref.Part2.26">6.3</a>, <a href="#rfc.xref.Part2.27">6.4</a>, <a href="#rfc.xref.Part2.28">7.4</a>, <a href="#rfc.xref.Part2.29">8.6</a>, <a href="#rfc.xref.Part2.30">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul> 3668 <li><em>Section 3</em> <a href="#rfc.xref.Part2.5">3.1.1</a></li> 3669 <li><em>Section 3.2.2</em> <a href="#rfc.xref.Part2.22">6.2.2.1</a>, <a href="#rfc.xref.Part2.23">6.2.2.2</a></li> 3670 <li><em>Section 3.3.1</em> <a href="#rfc.xref.Part2.14">5.3</a></li> 3671 <li><em>Section 3.3.8</em> <a href="#rfc.xref.Part2.13">5.3</a></li> 3672 <li><em>Section 4.5</em> <a href="#rfc.xref.Part2.9">3.2</a></li> 3673 <li><em>Section 5</em> <a href="#rfc.xref.Part2.4">2.7.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a></li> 3674 <li><em>Section 5.2</em> <a href="#rfc.xref.Part2.21">5.9</a>, <a href="#rfc.xref.Part2.26">6.3</a></li> 3675 <li><em>Section 5.2.1</em> <a href="#rfc.xref.Part2.24">6.3</a></li> 3676 <li><em>Section 5.3.4</em> <a href="#rfc.xref.Part2.3">2.3</a></li> 3677 <li><em>Section 5.4</em> <a href="#rfc.xref.Part2.27">6.4</a></li> 3678 <li><em>Section 5.5</em> <a href="#rfc.xref.Part2.30">8.6</a></li> 3679 <li><em>Section 5.5.12</em> <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.29">8.6</a></li> 3680 <li><em>Section 6.4</em> <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.28">7.4</a></li> 3681 <li><em>Section 9.3</em> <a href="#rfc.xref.Part2.11">4.3</a></li> 3682 <li><em>Section 10.5</em> <a href="#rfc.xref.Part2.16">5.8</a></li> 3683 <li><em>Section 10.6</em> <a href="#rfc.xref.Part2.19">5.8</a></li> 3684 <li><em>Section 10.8</em> <a href="#rfc.xref.Part2.17">5.8</a></li> 3685 <li><em>Section 10.9</em> <a href="#rfc.xref.Part2.20">5.8</a></li> 3686 <li><em>Section 10.10</em> <a href="#rfc.xref.Part2.8">3.2</a></li> 3687 <li><em>Section 10.11</em> <a href="#rfc.xref.Part2.25">6.3</a></li> 3688 <li><em>Section 10.17</em> <a href="#rfc.xref.Part2.18">5.8</a></li> 3617 <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.3</a>, <a href="#rfc.xref.Part2.4">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5.8</a>, <a href="#rfc.xref.Part2.16">5.8</a>, <a href="#rfc.xref.Part2.17">5.8</a>, <a href="#rfc.xref.Part2.18">5.8</a>, <a href="#rfc.xref.Part2.19">5.8</a>, <a href="#rfc.xref.Part2.20">5.8</a>, <a href="#rfc.xref.Part2.21">5.9</a>, <a href="#rfc.xref.Part2.22">6.2.2.1</a>, <a href="#rfc.xref.Part2.23">6.2.2.2</a>, <a href="#rfc.xref.Part2.24">6.3</a>, <a href="#rfc.xref.Part2.25">7.4</a>, <a href="#rfc.xref.Part2.26">8.6</a>, <a href="#rfc.xref.Part2.27">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul> 3618 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part2.20">5.8</a></li> 3619 <li><em>Section 3.2.2</em> <a href="#rfc.xref.Part2.19">5.8</a></li> 3620 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part2.17">5.8</a></li> 3621 <li><em>Section 5</em> <a href="#rfc.xref.Part2.5">3.1.1</a></li> 3622 <li><em>Section 5.2.2</em> <a href="#rfc.xref.Part2.22">6.2.2.1</a>, <a href="#rfc.xref.Part2.23">6.2.2.2</a></li> 3623 <li><em>Section 5.3.6</em> <a href="#rfc.xref.Part2.13">5.3</a></li> 3624 <li><em>Section 5.3.7</em> <a href="#rfc.xref.Part2.14">5.3</a></li> 3625 <li><em>Section 6.3.1</em> <a href="#rfc.xref.Part2.11">4.3</a></li> 3626 <li><em>Section 7</em> <a href="#rfc.xref.Part2.4">2.7.1</a>, <a href="#rfc.xref.Part2.7">3.1.2</a></li> 3627 <li><em>Section 7.2</em> <a href="#rfc.xref.Part2.21">5.9</a></li> 3628 <li><em>Section 7.3.4</em> <a href="#rfc.xref.Part2.3">2.3</a></li> 3629 <li><em>Section 7.4</em> <a href="#rfc.xref.Part2.24">6.3</a></li> 3630 <li><em>Section 7.5</em> <a href="#rfc.xref.Part2.27">8.6</a></li> 3631 <li><em>Section 7.5.12</em> <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.26">8.6</a></li> 3632 <li><em>Section 8.2.1</em> <a href="#rfc.xref.Part2.8">3.2</a></li> 3633 <li><em>Section 8.4.1</em> <a href="#rfc.xref.Part2.16">5.8</a></li> 3634 <li><em>Section 8.4.2</em> <a href="#rfc.xref.Part2.18">5.8</a></li> 3635 <li><em>Section 9.4</em> <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.25">7.4</a></li> 3636 <li><em>Section 10.3.1</em> <a href="#rfc.xref.Part2.9">3.2</a></li> 3689 3637 <li><em>Appendix A</em> <a href="#rfc.xref.Part2.2">2.1</a></li> 3690 3638 </ul> … … 3729 3677 </li> 3730 3678 <li><em>RFC2047</em> <a href="#rfc.xref.RFC2047.1">3.2.2</a>, <a href="#RFC2047"><b>10.2</b></a></li> 3731 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">1</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">6.2.1</a>, <a href="#rfc.xref.RFC2068.4"> 6.3</a>, <a href="#rfc.xref.RFC2068.5">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.6">A.1.2</a><ul>3732 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068.3">6.2.1</a>, <a href="#rfc.xref.RFC2068. 6">A.1.2</a></li>3679 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">1</a>, <a href="#rfc.xref.RFC2068.2">2.6</a>, <a href="#rfc.xref.RFC2068.3">6.2.1</a>, <a href="#rfc.xref.RFC2068.4">9</a>, <a href="#RFC2068"><b>10.2</b></a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a><ul> 3680 <li><em>Section 19.7.1</em> <a href="#rfc.xref.RFC2068.3">6.2.1</a>, <a href="#rfc.xref.RFC2068.5">A.1.2</a></li> 3733 3681 </ul> 3734 3682 </li> … … 3800 3748 </li> 3801 3749 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 3802 <li>Upgrade header field <a href="#rfc.iref.u.5"><b>6. 4</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li>3750 <li>Upgrade header field <a href="#rfc.iref.u.5"><b>6.3</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li> 3803 3751 <li>upstream <a href="#rfc.iref.u.2"><b>2.3</b></a></li> 3804 3752 <li>URI scheme
Note: See TracChangeset
for help on using the changeset viewer.
