Changeset 1863 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 04/09/12 08:58:08 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1862 r1863 1264 1264 </div> 1265 1265 <div id="rule.BWS"> 1266 <p id="rfc.section.3.2.1.p.4">BWS is used where the grammar allows optional whitespace for historical reasons but senders <em class="bcp14">SHOULD NOT</em> produce it in messages. HTTP/1.1recipients <em class="bcp14">MUST</em> accept such bad optional whitespace and remove it before interpreting the field value or forwarding the message downstream.1266 <p id="rfc.section.3.2.1.p.4">BWS is used where the grammar allows optional whitespace, for historical reasons, but senders <em class="bcp14">SHOULD NOT</em> produce it in messages; recipients <em class="bcp14">MUST</em> accept such bad optional whitespace and remove it before interpreting the field value or forwarding the message downstream. 1267 1267 </p> 1268 1268 </div> … … 1302 1302 <h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a> <a id="field.components" href="#field.components">Field value components</a></h3> 1303 1303 <div id="rule.token.separators"> 1304 <p id="rfc.section.3.2.4.p.1"> Many HTTP /1.1 header field values consist of words (token or quoted-string) separated by whitespace or special characters.1305 Thesespecial characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section 4</a>).1304 <p id="rfc.section.3.2.4.p.1"> Many HTTP header field values consist of words (token or quoted-string) separated by whitespace or special characters. These 1305 special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section 4</a>). 1306 1306 </p> 1307 1307 </div> … … 1487 1487 </p> 1488 1488 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="incomplete.messages" href="#incomplete.messages">Handling Incomplete Messages</a></h2> 1489 <p id="rfc.section.3.4.p.1">Request messages that are prematurely terminated, possibly due to a canceled connection or a server-imposed time-out exception, <em class="bcp14">MUST</em> result in closure of the connection; sending an HTTP/1.1error response prior to closing the connection is <em class="bcp14">OPTIONAL</em>.1489 <p id="rfc.section.3.4.p.1">Request messages that are prematurely terminated, possibly due to a canceled connection or a server-imposed time-out exception, <em class="bcp14">MUST</em> result in closure of the connection; sending an error response prior to closing the connection is <em class="bcp14">OPTIONAL</em>. 1490 1490 </p> 1491 1491 <p id="rfc.section.3.4.p.2">Response messages that are prematurely terminated, usually by closure of the connection prior to receiving the expected number … … 1535 1535 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#rule.token.separators" class="smpl">token</a> 1536 1536 <a href="#rule.parameter" class="smpl">value</a> = <a href="#rule.token.separators" class="smpl">word</a> 1537 </pre><p id="rfc.section.4.p.5">All transfer-coding values are case-insensitive . The HTTP Transfer Coding registry is defined in <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 7.4</a>. HTTP/1.1 uses transfer-coding values in the <a href="#header.te" class="smpl">TE</a> header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section 4.3</a>) and in the <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 3.3.1</a>).1537 </pre><p id="rfc.section.4.p.5">All transfer-coding values are case-insensitive and <em class="bcp14">SHOULD</em> be registered within the HTTP Transfer Coding registry, as defined in <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 7.4</a>. They are used in the <a href="#header.te" class="smpl">TE</a> (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section 4.3</a>) and <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section 3.3.1</a>) header fields. 1538 1538 </p> 1539 1539 <div id="rfc.iref.c.7"></div> … … 1614 1614 Remove "chunked" from Transfer-Encoding 1615 1615 Remove Trailer from existing header fields 1616 </pre><p id="rfc.section.4.1.2.p.3">All HTTP/1.1 applications <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand.1616 </pre><p id="rfc.section.4.1.2.p.3">All recipients <em class="bcp14">MUST</em> be able to receive and decode the "chunked" transfer-coding and <em class="bcp14">MUST</em> ignore chunk-ext extensions they do not understand. 1617 1617 </p> 1618 1618 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="compression.codings" href="#compression.codings">Compression Codings</a></h2> … … 1778 1778 to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host. 1779 1779 </p> 1780 <p id="rfc.section.5.4.p.7">When a n HTTP/1.1proxy receives a request with an absolute-form of request-target, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. If1780 <p id="rfc.section.5.4.p.7">When a proxy receives a request with an absolute-form of request-target, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. If 1781 1781 the proxy forwards the request, it <em class="bcp14">MUST</em> generate a new Host field-value based on the received request-target rather than forward the received Host field-value. 1782 1782 </p> … … 1948 1948 <div id="rfc.iref.c.13"></div> 1949 1949 <div id="rfc.iref.h.13"></div> 1950 <div id="rfc.iref.c.14"></div> 1950 1951 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="header.connection" href="#header.connection">Connection</a></h2> 1951 1952 <p id="rfc.section.6.1.p.1">The "Connection" header field allows the sender to indicate desired control options for the current connection. In order to … … 1964 1965 <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span> <a href="#header.connection" class="smpl">Connection</a> = 1#<a href="#header.connection" class="smpl">connection-option</a> 1965 1966 <a href="#header.connection" class="smpl">connection-option</a> = <a href="#rule.token.separators" class="smpl">token</a> 1966 </pre><p id="rfc.section.6.1.p.6">Connection options are c ompared case-insensitively.</p>1967 </pre><p id="rfc.section.6.1.p.6">Connection options are case-insensitive.</p> 1967 1968 <p id="rfc.section.6.1.p.7">A sender <em class="bcp14">MUST NOT</em> include field-names in the Connection header field-value for fields that are defined as expressing constraints for all recipients 1968 1969 in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.9"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). … … 1980 1981 connection option, since it would be unwise for senders to use that field-name for anything else. 1981 1982 </p> 1982 <p id="rfc.section.6.1.p.10">HTTP/1.1 defines the "<dfn>close</dfn>" connection option for the sender to signal that this connection will be closed after completion of the response. For example, 1983 <p id="rfc.section.6.1.p.10">The "<dfn>close</dfn>" connection option is defined for a sender to signal that this connection will be closed after completion of the response. 1984 For example, 1983 1985 </p> 1984 1986 <div id="rfc.figure.u.56"></div><pre class="text"> Connection: close 1985 </pre><p id="rfc.section.6.1.p.12">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD</em> be closed after the current request/response is complete (<a href="#persistent. connections" title="Persistent Connections">Section 6.2</a>).1986 </p> 1987 <p id="rfc.section.6.1.p.13">A n HTTP/1.1 client that does not support persistent connections <em class="bcp14">MUST</em> includethe "close" connection option in every request message.1988 </p> 1989 <p id="rfc.section.6.1.p.14">A n HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> includethe "close" connection option in every response message that does not have a <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> status code.1987 </pre><p id="rfc.section.6.1.p.12">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD</em> be closed after the current request/response is complete (<a href="#persistent.tear-down" id="rfc.xref.persistent.tear-down.1" title="Tear-down">Section 6.2.5</a>). 1988 </p> 1989 <p id="rfc.section.6.1.p.13">A client that does not support persistent connections <em class="bcp14">MUST</em> send the "close" connection option in every request message. 1990 </p> 1991 <p id="rfc.section.6.1.p.14">A server that does not support persistent connections <em class="bcp14">MUST</em> send the "close" connection option in every response message that does not have a <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> status code. 1990 1992 </p> 1991 1993 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2> … … 2017 2019 </p> 2018 2020 <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a> <a id="persistent.establishment" href="#persistent.establishment">Establishment</a></h3> 2019 <p id="rfc.section.6.2.1.p.1">Each connection applies to only one transport link.</p> 2020 <p id="rfc.section.6.2.1.p.2">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a <a href="#header.connection" class="smpl">Connection</a> header field including the connection option "close" was sent in the request. 2021 </p> 2022 <p id="rfc.section.6.2.1.p.3">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains 2023 a <a href="#header.connection" class="smpl">Connection</a> header field with the connection option "close". 2024 </p> 2025 <p id="rfc.section.6.2.1.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients. 2026 </p> 2027 <p id="rfc.section.6.2.1.p.5">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <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.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients). 2021 <p id="rfc.section.6.2.1.p.1">It is beyond the scope of this specification to describe how connections are established via various transport or session-layer 2022 protocols. Each connection applies to only one transport link. 2023 </p> 2024 <p id="rfc.section.6.2.1.p.2">A recipient determines whether a connection is persistent or not based on the most recently received message's protocol version 2025 and <a href="#header.connection" class="smpl">Connection</a> header field (if any): 2026 </p> 2027 <ul> 2028 <li>If the <a href="#header.connection" class="smpl">close</a> connection option is present, the connection will not persist after the current response; else, 2029 </li> 2030 <li>If the received protocol is HTTP/1.1 (or later), the connection will persist after the current response; else,</li> 2031 <li>If the received protocol is HTTP/1.0, the "keep-alive" connection option is present, the recipient is not a proxy, and the 2032 recipient wishes to honor the HTTP/1.0 "keep-alive" mechanism, the connection will persist after the current response; otherwise, 2033 </li> 2034 <li>The connection will close after the current response.</li> 2035 </ul> 2036 <p id="rfc.section.6.2.1.p.3">A proxy server <em class="bcp14">MUST NOT</em> maintain a persistent connection with an HTTP/1.0 client (see <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.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients). 2028 2037 </p> 2029 2038 <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a> <a id="persistent.reuse" href="#persistent.reuse">Reuse</a></h3> 2030 <p id="rfc.section.6.2.2.p.1">Unless otherwise indicated, the client <em class="bcp14">SHOULD</em> assume that the server will maintain a persistent connection, even after error responses from the server. 2031 </p> 2032 <p id="rfc.section.6.2.2.p.2">In order to remain persistent, all messages on the connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section 3.3</a>. 2039 <p id="rfc.section.6.2.2.p.1">In order to remain persistent, all messages on a connection <em class="bcp14">MUST</em> have a self-defined message length (i.e., one not defined by closure of the connection), as described in <a href="#message.body" title="Message Body">Section 3.3</a>. 2040 </p> 2041 <p id="rfc.section.6.2.2.p.2">A server <em class="bcp14">MAY</em> assume that an HTTP/1.1 client intends to maintain a persistent connection until a <a href="#header.connection" class="smpl">close</a> connection option is received in a request. 2042 </p> 2043 <p id="rfc.section.6.2.2.p.3">A client <em class="bcp14">MAY</em> reuse a persistent connection until it sends or receives a <a href="#header.connection" class="smpl">close</a> connection option or receives an HTTP/1.0 response without a "keep-alive" connection option. 2044 </p> 2045 <p id="rfc.section.6.2.2.p.4">Clients and servers <em class="bcp14">SHOULD NOT</em> assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients. 2033 2046 </p> 2034 2047 <h4 id="rfc.section.6.2.2.1"><a href="#rfc.section.6.2.2.1">6.2.2.1</a> <a id="pipelining" href="#pipelining">Pipelining</a></h4> … … 2046 2059 </p> 2047 2060 <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a> <a id="persistent.concurrency" href="#persistent.concurrency">Concurrency</a></h3> 2048 <p id="rfc.section.6.2.3.p.1">Clients (including proxies) <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server (including proxies).2061 <p id="rfc.section.6.2.3.p.1">Clients <em class="bcp14">SHOULD</em> limit the number of simultaneous connections that they maintain to a given server. 2049 2062 </p> 2050 2063 <p id="rfc.section.6.2.3.p.2">Previous revisions of HTTP gave a specific number of connections as a ceiling, but this was found to be impractical for many … … 2052 2065 clients to be conservative when opening multiple connections. 2053 2066 </p> 2054 <p id="rfc.section.6.2.3.p.3">In particular, while using multiple connections avoids the "head-of-line blocking" problem (whereby a request that takes significant 2055 server-side processing and/or has a large payload can block subsequent requests on the same connection), each connection used 2056 consumes server resources (sometimes significantly), and furthermore using multiple connections can cause undesirable side 2057 effects in congested networks. 2067 <p id="rfc.section.6.2.3.p.3">Multiple connections are typically used to avoid the "head-of-line blocking" problem, wherein a request that takes significant 2068 server-side processing and/or has a large payload blocks subsequent requests on the same connection. However, each connection 2069 consumes server resources. Furthermore, using multiple connections can cause undesirable side effects in congested networks. 2058 2070 </p> 2059 2071 <p id="rfc.section.6.2.3.p.4">Note that servers might reject traffic that they deem abusive, including an excessive number of connections from a client.</p> … … 2071 2083 while it was idle, but from the client's point of view, a request is in progress. 2072 2084 </p> 2073 <p id="rfc.section.6.2.4.p.4">HTTP/1.1 servers <em class="bcp14">SHOULD</em> maintain persistent connections and use TCP's flow control mechanisms to resolve temporary overloads, rather than terminating 2074 connections with the expectation that clients will retry. The latter technique can exacerbate network congestion. 2075 </p> 2076 <p id="rfc.section.6.2.4.p.5">An HTTP/1.1 (or later) client sending a message body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error 2085 <p id="rfc.section.6.2.4.p.4">Servers <em class="bcp14">SHOULD</em> maintain persistent connections and allow the underlying transport's flow control mechanisms to resolve temporary overloads, 2086 rather than terminate connections with the expectation that clients will retry. The latter technique can exacerbate network 2087 congestion. 2088 </p> 2089 <p id="rfc.section.6.2.4.p.5">A client sending a message body <em class="bcp14">SHOULD</em> monitor the network connection for an error status code while it is transmitting the request. If the client sees an error 2077 2090 status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body and close the connection. 2078 2091 </p> 2092 <div id="rfc.iref.c.15"></div> 2093 <div id="rfc.iref.c.16"></div> 2079 2094 <h3 id="rfc.section.6.2.5"><a href="#rfc.section.6.2.5">6.2.5</a> <a id="persistent.tear-down" href="#persistent.tear-down">Tear-down</a></h3> 2080 <p id="rfc.section.6.2.5.p.1">Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling 2081 takes place using the <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 6.1</a>). Once a close has been signaled, the client <em class="bcp14">MUST NOT</em> send any more requests on that connection. 2082 </p> 2083 <p id="rfc.section.6.2.5.p.2">If either the client or the server sends the "close" option in the <a href="#header.connection" class="smpl">Connection</a> header field, that request/response pair becomes the last one for the connection. 2084 </p> 2085 <p id="rfc.section.6.2.5.p.3">If the server chooses to close the connection immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close". 2086 </p> 2087 <p id="rfc.section.6.2.5.p.4">In case the client does not want to maintain a connection for more than that request, it <em class="bcp14">SHOULD</em> send a Connection header field including the connection option "close". 2088 </p> 2089 <p id="rfc.section.6.2.5.p.5">If the client is sending data, a server implementation using TCP <em class="bcp14">SHOULD</em> be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes 2090 the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send 2091 a reset packet to the client, which might erase the client's unacknowledged input buffers before they can be read and interpreted 2092 by the HTTP application. 2093 </p> 2095 <p id="rfc.section.6.2.5.p.1">The <a href="#header.connection" class="smpl">Connection</a> header field (<a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 6.1</a>) provides a "<a href="#header.connection" class="smpl">close</a>" connection option that a sender <em class="bcp14">SHOULD</em> send when it wishes to close the connection after the current request/response pair. 2096 </p> 2097 <p id="rfc.section.6.2.5.p.2">A client that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST NOT</em> send further requests on that connection (after the one containing <a href="#header.connection" class="smpl">close</a>) and <em class="bcp14">MUST</em> close the connection after reading the final response message corresponding to this request. 2098 </p> 2099 <p id="rfc.section.6.2.5.p.3">A server that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close of the connection after it sends the final response to the request that contained <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">SHOULD</em> include a <a href="#header.connection" class="smpl">close</a> connection option in its final response on that connection. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection. 2100 </p> 2101 <p id="rfc.section.6.2.5.p.4">A server that sends a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> initiate a lingering close of the connection after it sends the response containing <a href="#header.connection" class="smpl">close</a>. The server <em class="bcp14">MUST NOT</em> process any further requests received on that connection. 2102 </p> 2103 <p id="rfc.section.6.2.5.p.5">A client that receives a <a href="#header.connection" class="smpl">close</a> connection option <em class="bcp14">MUST</em> cease sending requests on that connection and close the connection after reading the response message containing the close; 2104 if additional pipelined requests had been sent on the connection, the client <em class="bcp14">SHOULD</em> assume that they will not be processed by the server. 2105 </p> 2106 <p id="rfc.section.6.2.5.p.6">If a server performs an immediate close of a TCP connection, there is a significant risk that the client will not be able 2107 to read the last HTTP response. If the server receives additional data from the client on a fully-closed connection, such 2108 as another request that was sent by the client before receiving the server's response, the server's TCP stack will send a 2109 reset packet to the client; unfortunately, the reset packet might erase the client's unacknowledged input buffers before they 2110 can be read and interpreted by the client's HTTP parser. 2111 </p> 2112 <p id="rfc.section.6.2.5.p.7">To avoid the TCP reset problem, a server can perform a lingering close on a connection by closing only the write side of the 2113 read/write connection (a half-close) and continuing to read from the connection until the connection is closed by the client 2114 or the server is reasonably certain that its own TCP stack has received the client's acknowledgement of the packet(s) containing 2115 the server's last response. It is then safe for the server to fully close the connection. 2116 </p> 2117 <p id="rfc.section.6.2.5.p.8">It is unknown whether the reset problem is exclusive to TCP or might also be found in other transport connection protocols.</p> 2094 2118 <div id="rfc.iref.u.5"></div> 2095 2119 <div id="rfc.iref.h.14"></div> 2096 2120 <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 2098 server chooses to switch protocols. Servers can use it to indicate what protocols they are willing to switch to. 2121 <p id="rfc.section.6.3.p.1">The "Upgrade" header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other protocol 2122 on the same connection. A client <em class="bcp14">MAY</em> send a list of protocols in the Upgrade header field of a request to invite the server to switch to one or more of those protocols 2123 before sending the final response. A server <em class="bcp14">MUST</em> send an Upgrade header field in <a href="p2-semantics.html#status.101" class="smpl">101 (Switching 2124 Protocols)</a> responses to indicate which protocol(s) are being switched to, and <em class="bcp14">MUST</em> send it in <a href="p2-semantics.html#status.426" class="smpl">426 (Upgrade Required)</a> responses to indicate acceptable protocols. A server <em class="bcp14">MAY</em> send an Upgrade header field in any other response to indicate that they might be willing to upgrade to one of the specified 2125 protocols for a future request. 2099 2126 </p> 2100 2127 <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.93"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = 1#<a href="#header.upgrade" class="smpl">protocol</a> … … 2105 2132 </pre><p id="rfc.section.6.3.p.3">For example,</p> 2106 2133 <div id="rfc.figure.u.58"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2107 </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 2108 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP 2109 with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult 2110 transition between incompatible protocols by allowing the client to initiate a request in the more commonly supported protocol 2111 while indicating to the server that it would like to use a "better" protocol if available (where "better" is determined by 2112 the server, possibly according to the nature of the request method or target resource). 2113 </p> 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. 2115 Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities 2134 </pre><p id="rfc.section.6.3.p.5">Upgrade eases the difficult transition between incompatible protocols by allowing the client to initiate a request in the 2135 more commonly supported protocol while indicating to the server that it would like to use a "better" protocol if available 2136 (where "better" is determined by the server, possibly according to the nature of the request method or target resource). 2137 </p> 2138 <p id="rfc.section.6.3.p.6">Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities 2116 2139 and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen, 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. 2118 </p> 2119 <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 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. 2140 although the first action after changing the protocol <em class="bcp14">MUST</em> be a response to the initial HTTP request that contained the Upgrade header field. 2141 </p> 2142 <p id="rfc.section.6.3.p.7">For example, if the Upgrade header field is received in a GET request and the server decides to switch protocols, then it <em class="bcp14">MUST</em> first respond with a <a href="p2-semantics.html#status.101" class="smpl">101 (Switching Protocols)</a> message in HTTP/1.1 and then immediately follow that with the new protocol's equivalent of a response to a GET on the target 2143 resource. This allows a connection to be upgraded to protocols with the same semantics as HTTP without the latency cost of 2144 an additional round-trip. A server <em class="bcp14">MUST NOT</em> switch protocols unless the received message semantics can be honored by the new protocol; an OPTIONS request can be honored 2145 by any protocol. 2146 </p> 2147 <p id="rfc.section.6.3.p.8">When Upgrade is sent, a sender <em class="bcp14">MUST</em> also send 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>) that contains the "upgrade" connection option, in order to prevent Upgrade from being accidentally forwarded by intermediaries 2148 that might not implement the listed protocols. A server <em class="bcp14">MUST</em> ignore an Upgrade header field that is received in an HTTP/1.0 request. 2149 </p> 2150 <p id="rfc.section.6.3.p.9">The Upgrade header field only applies to switching application-layer protocols on the existing transport-layer connection; 2151 it cannot be used to switch to a protocol on a different connection. For that purpose, 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 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>). 2126 2152 </p> 2127 2153 <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 … … 3437 3463 <li>chunked (Coding Format) <a href="#rfc.iref.c.7">4.1</a></li> 3438 3464 <li>client <a href="#rfc.iref.c.1"><b>2.1</b></a></li> 3465 <li>close <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.14"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.16">6.2.5</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> 3439 3466 <li>Coding Format 3440 3467 <ul> … … 3447 3474 <li>compress (Coding Format) <a href="#rfc.iref.c.9">4.2.1</a></li> 3448 3475 <li>connection <a href="#rfc.iref.c.2"><b>2.1</b></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>3476 <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.persistent.tear-down.1">6.1</a>, <a href="#rfc.iref.c.15">6.2.5</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> 3450 3477 <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> 3451 3478 </ul>
Note: See TracChangeset
for help on using the changeset viewer.