Changeset 1863


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.

Location:
draft-ietf-httpbis/latest
Files:
2 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>

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

    r1861 r1863  
    12671267</t>
    12681268<t anchor="rule.BWS">
    1269    BWS is used where the grammar allows optional whitespace for historical
    1270    reasons but senders &SHOULD-NOT; produce it in messages. HTTP/1.1
     1269   BWS is used where the grammar allows optional whitespace, for historical
     1270   reasons, but senders &SHOULD-NOT; produce it in messages;
    12711271   recipients &MUST; accept such bad optional whitespace and remove it before
    12721272   interpreting the field value or forwarding the message downstream.
    … …  
    13561356  <x:anchor-alias value="special"/>
    13571357  <x:anchor-alias value="word"/>
    1358    Many HTTP/1.1 header field values consist of words (token or quoted-string)
     1358   Many HTTP header field values consist of words (token or quoted-string)
    13591359   separated by whitespace or special characters. These special characters
    13601360   &MUST; be in a quoted string to be used within a parameter value (as defined
    … …  
    17411741   Request messages that are prematurely terminated, possibly due to a
    17421742   canceled connection or a server-imposed time-out exception, &MUST;
    1743    result in closure of the connection; sending an HTTP/1.1 error response
     1743   result in closure of the connection; sending an error response
    17441744   prior to closing the connection is &OPTIONAL;.
    17451745</t>
    … …  
    18411841</artwork></figure>
    18421842<t>
    1843    All transfer-coding values are case-insensitive.
    1844    The HTTP Transfer Coding registry is defined in
     1843   All transfer-coding values are case-insensitive and &SHOULD; be registered
     1844   within the HTTP Transfer Coding registry, as defined in
    18451845   <xref target="transfer.coding.registry"/>.
    1846    HTTP/1.1 uses transfer-coding values in the <x:ref>TE</x:ref> header field
    1847    (<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.
    18491849</t>
    18501850
    … …  
    19801980</artwork></figure>
    19811981<t>
    1982    All HTTP/1.1 applications &MUST; be able to receive and decode the
     1982   All recipients &MUST; be able to receive and decode the
    19831983   "chunked" transfer-coding and &MUST; ignore chunk-ext extensions
    19841984   they do not understand.
    … …  
    23242324</t>
    23252325<t>
    2326    When an HTTP/1.1 proxy receives a request with an absolute-form of
     2326   When a proxy receives a request with an absolute-form of
    23272327   request-target, the proxy &MUST; ignore the received
    23282328   Host header field (if any) and instead replace it with the host
    … …  
    26782678  <iref primary="true" item="Connection header field" x:for-anchor=""/>
    26792679  <iref primary="true" item="Header Fields" subitem="Connection" x:for-anchor=""/>
     2680  <iref primary="true" item="close" x:for-anchor=""/>
    26802681  <x:anchor-alias value="Connection"/>
    26812682  <x:anchor-alias value="connection-option"/>
    … …  
    27152716</artwork></figure>
    27162717<t>
    2717    Connection options are compared case-insensitively.
     2718   Connection options are case-insensitive.
    27182719</t>
    27192720<t>
    … …  
    27472748</t>
    27482749<t>
    2749    HTTP/1.1 defines the "<x:dfn>close</x:dfn>" connection option for the
     2750   The "<x:dfn>close</x:dfn>" connection option is defined for a
    27502751   sender to signal that this connection will be closed after completion of
    27512752   the response. For example,
    … …  
    27572758   in either the request or the response header fields indicates that
    27582759   the connection &SHOULD; be closed after the current request/response
    2759    is complete (<xref target="persistent.connections"/>).
    2760 </t>
    2761 <t>
    2762    An HTTP/1.1 client that does not support persistent connections &MUST;
    2763    include the "close" connection option in every request message.
    2764 </t>
    2765 <t>
    2766    An HTTP/1.1 server that does not support persistent connections &MUST;
    2767    include the "close" connection option in every response message that
     2760   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
    27682769   does not have a <x:ref>1xx (Informational)</x:ref> status code.
    27692770</t>
    … …  
    28272828<section title="Establishment" anchor="persistent.establishment">
    28282829<t>
     2830   It is beyond the scope of this specification to describe how connections
     2831   are established via various transport or session-layer protocols.
    28292832   Each connection applies to only one transport link.
    28302833</t>
    28312834<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
    28522854   implemented by many HTTP/1.0 clients).
    28532855</t>
    … …  
    28562858<section title="Reuse" anchor="persistent.reuse">
    28572859<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;
    28642861   have a self-defined message length (i.e., one not defined by closure
    28652862   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.
    28662880</t>
    28672881
    … …  
    29112925<section title="Concurrency" anchor="persistent.concurrency">
    29122926<t>
    2913    Clients (including proxies) &SHOULD; limit the number of simultaneous
    2914    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.
    29152929</t>
    29162930<t>
    … …  
    29222936</t>
    29232937<t>
    2924    In particular, while using multiple connections avoids the "head-of-line
    2925    blocking" problem (whereby a request that takes significant server-side
    2926    processing and/or has a large payload can block subsequent requests on the
    2927    same connection), each connection used consumes server resources (sometimes
    2928    significantly), and furthermore using multiple connections can cause
    2929    undesirable side effects in 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.
    29302944</t>
    29312945<t>
    … …  
    29612975</t>
    29622976<t>
    2963    HTTP/1.1 servers &SHOULD; maintain persistent connections and use TCP's
    2964    flow control mechanisms to resolve temporary overloads, rather than
    2965    terminating connections 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.
    29662980   The latter technique can exacerbate network congestion.
    29672981</t>
    29682982<t>
    2969    An HTTP/1.1 (or later) client sending a message body &SHOULD; monitor
     2983   A client sending a message body &SHOULD; monitor
    29702984   the network connection for an error status code while it is transmitting
    29712985   the request. If the client sees an error status code, it &SHOULD;
    … …  
    29752989   
    29762990<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.
    30083048</t>
    30093049</section>
    … …  
    30183058  <x:anchor-alias value="protocol-version"/>
    30193059<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.
    30243072</t>
    30253073<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Upgrade"/>
    … …  
    30373085</artwork></figure>
    30383086<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
    30453088   allowing the client to initiate a request in the more commonly
    30463089   supported protocol while indicating to the server that it would like
    … …  
    30503093</t>
    30513094<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
    30563097   application-layer communication after the protocol change is entirely
    30573098   dependent upon the new protocol chosen, although the first action
    30583099   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
    30643115   <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;).
    30793127</t>
    30803128<t>
    … …  
    30863134</t>
    30873135</section>
    3088 
    30893136</section>
    30903137
Note: See TracChangeset for help on using the changeset viewer.