Ignore:
Timestamp:
Sep 4, 2012, 1:58:08 AM (7 years ago)
Author:
fielding@…
Message:

Rewrite the persistent connection and Upgrade requirements to be
actionable by role and consistent with the rest of HTTP.

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r1862 r1863  
    12641264      </div>
    12651265      <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.1 recipients <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.
    12671267         </p>
    12681268      </div>
    … …  
    13021302      <h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a>&nbsp;<a id="field.components" href="#field.components">Field value components</a></h3>
    13031303      <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             These 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&nbsp;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&nbsp;4</a>).
    13061306         </p>
    13071307      </div>
    … …  
    14871487      </p>
    14881488      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<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.1 error 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>.
    14901490      </p>
    14911491      <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
    … …  
    15351535  <a href="#rule.parameter" class="smpl">attribute</a>          = <a href="#rule.token.separators" class="smpl">token</a>
    15361536  <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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;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&nbsp;3.3.1</a>) header fields.
    15381538      </p>
    15391539      <div id="rfc.iref.c.7"></div>
    … …  
    16141614  Remove "chunked" from Transfer-Encoding
    16151615  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.
    16171617      </p>
    16181618      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="compression.codings" href="#compression.codings">Compression Codings</a></h2>
    … …  
    17781778         to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host.
    17791779      </p>
    1780       <p id="rfc.section.5.4.p.7">When an HTTP/1.1 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
     1780      <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
    17811781         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.
    17821782      </p>
    … …  
    19481948      <div id="rfc.iref.c.13"></div>
    19491949      <div id="rfc.iref.h.13"></div>
     1950      <div id="rfc.iref.c.14"></div>
    19501951      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="header.connection" href="#header.connection">Connection</a></h2>
    19511952      <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
    … …  
    19641965      <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>
    19651966  <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 compared case-insensitively.</p>
     1967</pre><p id="rfc.section.6.1.p.6">Connection options are case-insensitive.</p>
    19671968      <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
    19681969         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>).
    … …  
    19801981         connection option, since it would be unwise for senders to use that field-name for anything else.
    19811982      </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,
    19831985      </p>
    19841986      <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&nbsp;6.2</a>).
    1986       </p>
    1987       <p id="rfc.section.6.1.p.13">An HTTP/1.1 client that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every request message.
    1988       </p>
    1989       <p id="rfc.section.6.1.p.14">An HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> include 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.
     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&nbsp;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.
    19901992      </p>
    19911993      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2>
    … …  
    20172019      </p>
    20182020      <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;<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&nbsp;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).
    20282037      </p>
    20292038      <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;<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&nbsp;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&nbsp;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&nbsp;A.1.2</a> for more information on backward compatibility with HTTP/1.0 clients.
    20332046      </p>
    20342047      <h4 id="rfc.section.6.2.2.1"><a href="#rfc.section.6.2.2.1">6.2.2.1</a>&nbsp;<a id="pipelining" href="#pipelining">Pipelining</a></h4>
    … …  
    20462059      </p>
    20472060      <h3 id="rfc.section.6.2.3"><a href="#rfc.section.6.2.3">6.2.3</a>&nbsp;<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.
    20492062      </p>
    20502063      <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
    … …  
    20522065         clients to be conservative when opening multiple connections.
    20532066      </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.
    20582070      </p>
    20592071      <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>
    … …  
    20712083         while it was idle, but from the client's point of view, a request is in progress.
    20722084      </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
    20772090         status code, it <em class="bcp14">SHOULD</em> immediately cease transmitting the body and close the connection.
    20782091      </p>
     2092      <div id="rfc.iref.c.15"></div>
     2093      <div id="rfc.iref.c.16"></div>
    20792094      <h3 id="rfc.section.6.2.5"><a href="#rfc.section.6.2.5">6.2.5</a>&nbsp;<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&nbsp;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&nbsp;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>
    20942118      <div id="rfc.iref.u.5"></div>
    20952119      <div id="rfc.iref.h.14"></div>
    20962120      <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<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.
    20992126      </p>
    21002127      <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>
    … …  
    21052132</pre><p id="rfc.section.6.3.p.3">For example,</p>
    21062133      <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
    21162139         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&nbsp;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&nbsp;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>).
    21262152      </p>
    21272153      <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
    … …  
    34373463                  <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.7">4.1</a></li>
    34383464                  <li>client&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.1</b></a></li>
     3465                  <li>close&nbsp;&nbsp;<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>
    34393466                  <li>Coding Format&nbsp;&nbsp;
    34403467                     <ul>
    … …  
    34473474                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.9">4.2.1</a></li>
    34483475                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3449                   <li>Connection header field&nbsp;&nbsp;<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&nbsp;&nbsp;<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>
    34503477                  <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.iref.c.6"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">7.1</a></li>
    34513478               </ul>
Note: See TracChangeset for help on using the changeset viewer.