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.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.