Changeset 1863
- Timestamp:
- 04/09/12 08:58:08 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 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> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1861 r1863 1267 1267 </t> 1268 1268 <t anchor="rule.BWS"> 1269 BWS is used where the grammar allows optional whitespace for historical1270 reasons but senders &SHOULD-NOT; produce it in messages. HTTP/1.11269 BWS is used where the grammar allows optional whitespace, for historical 1270 reasons, but senders &SHOULD-NOT; produce it in messages; 1271 1271 recipients &MUST; accept such bad optional whitespace and remove it before 1272 1272 interpreting the field value or forwarding the message downstream. … … 1356 1356 <x:anchor-alias value="special"/> 1357 1357 <x:anchor-alias value="word"/> 1358 Many HTTP /1.1header field values consist of words (token or quoted-string)1358 Many HTTP header field values consist of words (token or quoted-string) 1359 1359 separated by whitespace or special characters. These special characters 1360 1360 &MUST; be in a quoted string to be used within a parameter value (as defined … … 1741 1741 Request messages that are prematurely terminated, possibly due to a 1742 1742 canceled connection or a server-imposed time-out exception, &MUST; 1743 result in closure of the connection; sending an HTTP/1.1error response1743 result in closure of the connection; sending an error response 1744 1744 prior to closing the connection is &OPTIONAL;. 1745 1745 </t> … … 1841 1841 </artwork></figure> 1842 1842 <t> 1843 All transfer-coding values are case-insensitive .1844 The HTTP Transfer Coding registry is defined in1843 All transfer-coding values are case-insensitive and &SHOULD; be registered 1844 within the HTTP Transfer Coding registry, as defined in 1845 1845 <xref target="transfer.coding.registry"/>. 1846 HTTP/1.1 uses transfer-coding values in the <x:ref>TE</x:ref> header field1847 (<xref target="header.te"/>) and in the <x:ref>Transfer-Encoding</x:ref>1848 header field (<xref target="header.transfer-encoding"/>).1846 They are used in the <x:ref>TE</x:ref> (<xref target="header.te"/>) and 1847 <x:ref>Transfer-Encoding</x:ref> (<xref target="header.transfer-encoding"/>) 1848 header fields. 1849 1849 </t> 1850 1850 … … 1980 1980 </artwork></figure> 1981 1981 <t> 1982 All HTTP/1.1 applications &MUST; be able to receive and decode the1982 All recipients &MUST; be able to receive and decode the 1983 1983 "chunked" transfer-coding and &MUST; ignore chunk-ext extensions 1984 1984 they do not understand. … … 2324 2324 </t> 2325 2325 <t> 2326 When a n HTTP/1.1proxy receives a request with an absolute-form of2326 When a proxy receives a request with an absolute-form of 2327 2327 request-target, the proxy &MUST; ignore the received 2328 2328 Host header field (if any) and instead replace it with the host … … 2678 2678 <iref primary="true" item="Connection header field" x:for-anchor=""/> 2679 2679 <iref primary="true" item="Header Fields" subitem="Connection" x:for-anchor=""/> 2680 <iref primary="true" item="close" x:for-anchor=""/> 2680 2681 <x:anchor-alias value="Connection"/> 2681 2682 <x:anchor-alias value="connection-option"/> … … 2715 2716 </artwork></figure> 2716 2717 <t> 2717 Connection options are c ompared case-insensitively.2718 Connection options are case-insensitive. 2718 2719 </t> 2719 2720 <t> … … 2747 2748 </t> 2748 2749 <t> 2749 HTTP/1.1 defines the "<x:dfn>close</x:dfn>" connection option for the2750 The "<x:dfn>close</x:dfn>" connection option is defined for a 2750 2751 sender to signal that this connection will be closed after completion of 2751 2752 the response. For example, … … 2757 2758 in either the request or the response header fields indicates that 2758 2759 the connection &SHOULD; be closed after the current request/response 2759 is complete (<xref target="persistent. connections"/>).2760 </t> 2761 <t> 2762 A n HTTP/1.1client that does not support persistent connections &MUST;2763 includethe "close" connection option in every request message.2764 </t> 2765 <t> 2766 A n HTTP/1.1server that does not support persistent connections &MUST;2767 includethe "close" connection option in every response message that2760 is complete (<xref target="persistent.tear-down"/>). 2761 </t> 2762 <t> 2763 A client that does not support persistent connections &MUST; 2764 send the "close" connection option in every request message. 2765 </t> 2766 <t> 2767 A server that does not support persistent connections &MUST; 2768 send the "close" connection option in every response message that 2768 2769 does not have a <x:ref>1xx (Informational)</x:ref> status code. 2769 2770 </t> … … 2827 2828 <section title="Establishment" anchor="persistent.establishment"> 2828 2829 <t> 2830 It is beyond the scope of this specification to describe how connections 2831 are established via various transport or session-layer protocols. 2829 2832 Each connection applies to only one transport link. 2830 2833 </t> 2831 2834 <t> 2832 An HTTP/1.1 server &MAY; assume that a HTTP/1.1 client intends to 2833 maintain a persistent connection unless a <x:ref>Connection</x:ref> header 2834 field including the connection option "close" was sent in the request. 2835 </t> 2836 <t> 2837 An HTTP/1.1 client &MAY; expect a connection to remain open, but would 2838 decide to keep it open based on whether the response from a server 2839 contains a <x:ref>Connection</x:ref> header field with the connection option 2840 "close". 2841 </t> 2842 <t> 2843 Clients and servers &SHOULD-NOT; assume that a persistent connection is 2844 maintained for HTTP versions less than 1.1 unless it is explicitly 2845 signaled. See <xref target="compatibility.with.http.1.0.persistent.connections"/> for more information on backward 2846 compatibility with HTTP/1.0 clients. 2847 </t> 2848 <t> 2849 A proxy server &MUST-NOT; establish a HTTP/1.1 persistent connection 2850 with an HTTP/1.0 client (but see <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/> 2851 for information and discussion of the problems with the Keep-Alive header field 2835 A recipient determines whether a connection is persistent or not based on 2836 the most recently received message's protocol version and 2837 <x:ref>Connection</x:ref> header field (if any): 2838 <list style="symbols"> 2839 <t>If the <x:ref>close</x:ref> connection option is present, the 2840 connection will not persist after the current response; else,</t> 2841 <t>If the received protocol is HTTP/1.1 (or later), the connection will 2842 persist after the current response; else,</t> 2843 <t>If the received protocol is HTTP/1.0, the "keep-alive" 2844 connection option is present, the recipient is not a proxy, and 2845 the recipient wishes to honor the HTTP/1.0 "keep-alive" mechanism, 2846 the connection will persist after the current response; otherwise,</t> 2847 <t>The connection will close after the current response.</t> 2848 </list> 2849 </t> 2850 <t> 2851 A proxy server &MUST-NOT; maintain a persistent connection with an 2852 HTTP/1.0 client (see <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/> for 2853 information and discussion of the problems with the Keep-Alive header field 2852 2854 implemented by many HTTP/1.0 clients). 2853 2855 </t> … … 2856 2858 <section title="Reuse" anchor="persistent.reuse"> 2857 2859 <t> 2858 Unless otherwise indicated, the client 2859 &SHOULD; assume that the server will maintain a persistent connection, 2860 even after error responses from the server. 2861 </t> 2862 <t> 2863 In order to remain persistent, all messages on the connection &MUST; 2860 In order to remain persistent, all messages on a connection &MUST; 2864 2861 have a self-defined message length (i.e., one not defined by closure 2865 2862 of the connection), as described in <xref target="message.body"/>. 2863 </t> 2864 <t> 2865 A server &MAY; assume that an HTTP/1.1 client intends to maintain a 2866 persistent connection until a <x:ref>close</x:ref> connection option 2867 is received in a request. 2868 </t> 2869 <t> 2870 A client &MAY; reuse a persistent connection until it sends or receives 2871 a <x:ref>close</x:ref> connection option or receives an HTTP/1.0 response 2872 without a "keep-alive" connection option. 2873 </t> 2874 <t> 2875 Clients and servers &SHOULD-NOT; assume that a persistent connection is 2876 maintained for HTTP versions less than 1.1 unless it is explicitly 2877 signaled. 2878 See <xref target="compatibility.with.http.1.0.persistent.connections"/> 2879 for more information on backward compatibility with HTTP/1.0 clients. 2866 2880 </t> 2867 2881 … … 2911 2925 <section title="Concurrency" anchor="persistent.concurrency"> 2912 2926 <t> 2913 Clients (including proxies)&SHOULD; limit the number of simultaneous2914 connections that they maintain to a given server (including proxies).2927 Clients &SHOULD; limit the number of simultaneous 2928 connections that they maintain to a given server. 2915 2929 </t> 2916 2930 <t> … … 2922 2936 </t> 2923 2937 <t> 2924 In particular, while using multiple connections avoidsthe "head-of-line2925 blocking" problem (wherebya request that takes significant server-side2926 processing and/or has a large payload can blocksubsequent requests on the2927 same connection ), each connection used consumes server resources (sometimes2928 significantly), and furthermore using multiple connections can cause2929 undesirable side effectsin congested networks.2938 Multiple connections are typically used to avoid the "head-of-line 2939 blocking" problem, wherein a request that takes significant server-side 2940 processing and/or has a large payload blocks subsequent requests on the 2941 same connection. However, each connection consumes server resources. 2942 Furthermore, using multiple connections can cause undesirable side effects 2943 in congested networks. 2930 2944 </t> 2931 2945 <t> … … 2961 2975 </t> 2962 2976 <t> 2963 HTTP/1.1 servers &SHOULD; maintain persistent connections and use TCP's2964 flow control mechanisms to resolve temporary overloads, rather than2965 t erminatingconnections with the expectation that clients will retry.2977 Servers &SHOULD; maintain persistent connections and allow the underlying 2978 transport's flow control mechanisms to resolve temporary overloads, rather 2979 than terminate connections with the expectation that clients will retry. 2966 2980 The latter technique can exacerbate network congestion. 2967 2981 </t> 2968 2982 <t> 2969 A n HTTP/1.1 (or later)client sending a message body &SHOULD; monitor2983 A client sending a message body &SHOULD; monitor 2970 2984 the network connection for an error status code while it is transmitting 2971 2985 the request. If the client sees an error status code, it &SHOULD; … … 2975 2989 2976 2990 <section title="Tear-down" anchor="persistent.tear-down"> 2977 <t> 2978 Persistent connections provide a mechanism by which a client and a 2979 server can signal the close of a TCP connection. This signaling takes 2980 place using the <x:ref>Connection</x:ref> header field 2981 (<xref target="header.connection"/>). Once a close has been signaled, the 2982 client &MUST-NOT; send any more requests on that 2983 connection. 2984 </t> 2985 <t> 2986 If either the client or the server sends the "close" option in the 2987 <x:ref>Connection</x:ref> header field, that request/response pair 2988 becomes the last one for the connection. 2989 </t> 2990 <t> 2991 If the server chooses to close the connection immediately after sending the 2992 response, it &SHOULD; send a Connection header field including the 2993 connection option "close". 2994 </t> 2995 <t> 2996 In case the client does not want to maintain a connection for more 2997 than that request, it &SHOULD; send a Connection header field including the 2998 connection option "close". 2999 </t> 3000 <t> 3001 If the client is sending data, a server implementation using TCP 3002 &SHOULD; be careful to ensure that the client acknowledges receipt of 3003 the packet(s) containing the response, before the server closes the 3004 input connection. If the client continues sending data to the server 3005 after the close, the server's TCP stack will send a reset packet to 3006 the client, which might erase the client's unacknowledged input buffers 3007 before they can be read and interpreted by the HTTP application. 2991 <iref primary="false" item="Connection header field" x:for-anchor=""/> 2992 <iref primary="false" item="close" x:for-anchor=""/> 2993 <t> 2994 The <x:ref>Connection</x:ref> header field 2995 (<xref target="header.connection"/>) provides a "<x:ref>close</x:ref>" 2996 connection option that a sender &SHOULD; send when it wishes to close 2997 the connection after the current request/response pair. 2998 </t> 2999 <t> 3000 A client that sends a <x:ref>close</x:ref> connection option &MUST-NOT; 3001 send further requests on that connection (after the one containing 3002 <x:ref>close</x:ref>) and &MUST; close the connection after reading the 3003 final response message corresponding to this request. 3004 </t> 3005 <t> 3006 A server that receives a <x:ref>close</x:ref> connection option &MUST; 3007 initiate a lingering close of the connection after it sends the final 3008 response to the request that contained <x:ref>close</x:ref>. 3009 The server &SHOULD; include a <x:ref>close</x:ref> connection option 3010 in its final response on that connection. The server &MUST-NOT; process 3011 any further requests received on that connection. 3012 </t> 3013 <t> 3014 A server that sends a <x:ref>close</x:ref> connection option &MUST; 3015 initiate a lingering close of the connection after it sends the 3016 response containing <x:ref>close</x:ref>. The server &MUST-NOT; process 3017 any further requests received on that connection. 3018 </t> 3019 <t> 3020 A client that receives a <x:ref>close</x:ref> connection option &MUST; 3021 cease sending requests on that connection and close the connection 3022 after reading the response message containing the close; if additional 3023 pipelined requests had been sent on the connection, the client &SHOULD; 3024 assume that they will not be processed by the server. 3025 </t> 3026 <t> 3027 If a server performs an immediate close of a TCP connection, there is a 3028 significant risk that the client will not be able to read the last HTTP 3029 response. If the server receives additional data from the client on a 3030 fully-closed connection, such as another request that was sent by the 3031 client before receiving the server's response, the server's TCP stack will 3032 send a reset packet to the client; unfortunately, the reset packet might 3033 erase the client's unacknowledged input buffers before they can be read 3034 and interpreted by the client's HTTP parser. 3035 </t> 3036 <t> 3037 To avoid the TCP reset problem, a server can perform a lingering close on a 3038 connection by closing only the write side of the read/write connection 3039 (a half-close) and continuing to read from the connection until the 3040 connection is closed by the client or the server is reasonably certain 3041 that its own TCP stack has received the client's acknowledgement of the 3042 packet(s) containing the server's last response. It is then safe for the 3043 server to fully close the connection. 3044 </t> 3045 <t> 3046 It is unknown whether the reset problem is exclusive to TCP or might also 3047 be found in other transport connection protocols. 3008 3048 </t> 3009 3049 </section> … … 3018 3058 <x:anchor-alias value="protocol-version"/> 3019 3059 <t> 3020 The "Upgrade" header field allows the client to specify what 3021 additional communication protocols it would like to use, if the server 3022 chooses to switch protocols. Servers can use it to indicate what protocols 3023 they are willing to switch to. 3060 The "Upgrade" header field is intended to provide a simple mechanism 3061 for transitioning from HTTP/1.1 to some other protocol on the same 3062 connection. A client &MAY; send a list of protocols in the Upgrade 3063 header field of a request to invite the server to switch to one or 3064 more of those protocols before sending the final response. 3065 A server &MUST; send an Upgrade header field in <x:ref>101 (Switching 3066 Protocols)</x:ref> responses to indicate which protocol(s) are being 3067 switched to, and &MUST; send it in <x:ref>426 (Upgrade Required)</x:ref> 3068 responses to indicate acceptable protocols. 3069 A server &MAY; send an Upgrade header field in any other response to 3070 indicate that they might be willing to upgrade to one of the 3071 specified protocols for a future request. 3024 3072 </t> 3025 3073 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Upgrade"/> … … 3037 3085 </artwork></figure> 3038 3086 <t> 3039 The Upgrade header field is intended to provide a simple mechanism 3040 for transitioning from HTTP/1.1 to some other, incompatible protocol. It 3041 does so by allowing the client to advertise its desire to use another 3042 protocol, such as a later version of HTTP with a higher major version 3043 number, even though the current request has been made using HTTP/1.1. 3044 This eases the difficult transition between incompatible protocols by 3087 Upgrade eases the difficult transition between incompatible protocols by 3045 3088 allowing the client to initiate a request in the more commonly 3046 3089 supported protocol while indicating to the server that it would like … … 3050 3093 </t> 3051 3094 <t> 3052 The Upgrade header field only applies to switching application-layer 3053 protocols upon the existing transport-layer connection. Upgrade 3054 cannot be used to insist on a protocol change; its acceptance and use 3055 by the server is optional. The capabilities and nature of the 3095 Upgrade cannot be used to insist on a protocol change; its acceptance and 3096 use by the server is optional. The capabilities and nature of the 3056 3097 application-layer communication after the protocol change is entirely 3057 3098 dependent upon the new protocol chosen, although the first action 3058 3099 after changing the protocol &MUST; be a response to the initial HTTP 3059 request containing the Upgrade header field. 3060 </t> 3061 <t> 3062 The Upgrade header field only applies to the immediate connection. 3063 Therefore, the upgrade keyword &MUST; be supplied within a 3100 request that contained the Upgrade header field. 3101 </t> 3102 <t> 3103 For example, if the Upgrade header field is received in a GET request 3104 and the server decides to switch protocols, then it &MUST; first respond 3105 with a <x:ref>101 (Switching Protocols)</x:ref> message in HTTP/1.1 and 3106 then immediately follow that with the new protocol's equivalent of a 3107 response to a GET on the target resource. This allows a connection to be 3108 upgraded to protocols with the same semantics as HTTP without the 3109 latency cost of an additional round-trip. A server &MUST-NOT; switch 3110 protocols unless the received message semantics can be honored by the new 3111 protocol; an OPTIONS request can be honored by any protocol. 3112 </t> 3113 <t> 3114 When Upgrade is sent, a sender &MUST; also send a 3064 3115 <x:ref>Connection</x:ref> header field (<xref target="header.connection"/>) 3065 whenever Upgrade is present in an HTTP/1.1 message. 3066 </t> 3067 <t> 3068 The Upgrade header field cannot be used to indicate a switch to a 3069 protocol on a different connection. For that purpose, it is more 3070 appropriate to use a <x:ref>3xx (Redirection)</x:ref> response (&status-3xx;). 3071 </t> 3072 <t> 3073 Servers &MUST; include the "Upgrade" header field in <x:ref>101 (Switching 3074 Protocols)</x:ref> responses to indicate which protocol(s) are being switched to, 3075 and &MUST; include it in <x:ref>426 (Upgrade Required)</x:ref> responses to indicate 3076 acceptable protocols to upgrade to. Servers &MAY; include it in any other 3077 response to indicate that they are willing to upgrade to one of the 3078 specified protocols. 3116 that contains the "upgrade" connection option, in order to prevent Upgrade 3117 from being accidentally forwarded by intermediaries that might not implement 3118 the listed protocols. A server &MUST; ignore an Upgrade header field that 3119 is received in an HTTP/1.0 request. 3120 </t> 3121 <t> 3122 The Upgrade header field only applies to switching application-layer 3123 protocols on the existing transport-layer connection; it cannot be used 3124 to switch to a protocol on a different connection. For that purpose, it is 3125 more appropriate to use a <x:ref>3xx (Redirection)</x:ref> response 3126 (&status-3xx;). 3079 3127 </t> 3080 3128 <t> … … 3086 3134 </t> 3087 3135 </section> 3088 3089 3136 </section> 3090 3137
Note: See TracChangeset
for help on using the changeset viewer.