Ignore:
Timestamp:
Aug 20, 2012, 1:33:10 AM (7 years ago)
Author:
fielding@…
Message:

reorganize the persistent connection requirements into sections that correspond to implementation states

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1837 r1838  
    26822682  <x:anchor-alias value="Connection"/>
    26832683  <x:anchor-alias value="connection-option"/>
     2684  <x:anchor-alias value="close"/>
    26842685<t>
    26852686   The "Connection" header field allows the sender to indicate desired
     
    27482749</t>
    27492750<t>
    2750    HTTP/1.1 defines the "close" connection option for the sender to
    2751    signal that the connection will be closed after completion of the
    2752    response. For example,
     2751   HTTP/1.1 defines the "<x:dfn>close</x:dfn>" connection option for the
     2752   sender to signal that this connection will be closed after completion of
     2753   the response. For example,
    27532754</t>
    27542755<figure><artwork type="example">
     
    27872788   HTTP/1.1 defaults to the use of "<x:ref>persistent connections</x:ref>",
    27882789   which allow multiple requests and responses to be carried over a single
    2789    connection.
     2790   connection. The "<x:ref>close</x:ref>" connection-option is used to
     2791   signal that a connection will close after the current request/response.
    27902792   Persistent connections have a number of advantages:
    27912793  <list style="symbols">
     
    28242826   HTTP implementations &SHOULD; implement persistent connections.
    28252827</t>
    2826 
    2827 <section title="Overall Operation" anchor="persistent.overall">
    2828 <t>
    2829    A significant difference between HTTP/1.1 and earlier versions of
    2830    HTTP is that persistent connections are the default behavior of any
    2831    HTTP connection. That is, unless otherwise indicated, the client
    2832    &SHOULD; assume that the server will maintain a persistent connection,
    2833    even after error responses from the server.
    2834 </t>
    2835 <t>
    2836    Persistent connections provide a mechanism by which a client and a
    2837    server can signal the close of a TCP connection. This signaling takes
    2838    place using the <x:ref>Connection</x:ref> header field
    2839    (<xref target="header.connection"/>). Once a close has been signaled, the
    2840    client &MUST-NOT; send any more requests on that
    2841    connection.
    2842 </t>
    2843 
    2844 <section title="Negotiation" anchor="persistent.negotiation">
     2828   
     2829<section title="Establishment" anchor="persistent.establishment">
     2830<t>
     2831   Each connection applies to only one transport link.
     2832</t>
    28452833<t>
    28462834   An HTTP/1.1 server &MAY; assume that a HTTP/1.1 client intends to
    28472835   maintain a persistent connection unless a <x:ref>Connection</x:ref> header
    2848    field including the connection option "close" was sent in the request. If
    2849    the server chooses to close the connection immediately after sending the
    2850    response, it &SHOULD; send a Connection header field including the
    2851    connection option "close".
     2836   field including the connection option "close" was sent in the request.
    28522837</t>
    28532838<t>
     
    28552840   decide to keep it open based on whether the response from a server
    28562841   contains a <x:ref>Connection</x:ref> header field with the connection option
    2857    "close". In case the client does not want to maintain a connection for more
    2858    than that request, it &SHOULD; send a Connection header field including the
    2859    connection option "close".
    2860 </t>
    2861 <t>
    2862    If either the client or the server sends the "close" option in the
    2863    <x:ref>Connection</x:ref> header field, that request becomes the last one
    2864    for the connection.
     2842   "close".
    28652843</t>
    28662844<t>
     
    28712849</t>
    28722850<t>
    2873    Each persistent connection applies to only one transport link.
    2874 </t>
    2875 <t>
    28762851   A proxy server &MUST-NOT; establish a HTTP/1.1 persistent connection
    28772852   with an HTTP/1.0 client (but see <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>
     
    28792854   implemented by many HTTP/1.0 clients).
    28802855</t>
     2856</section>
     2857
     2858<section title="Reuse" anchor="persistent.reuse">
     2859<t>
     2860   Unless otherwise indicated, the client
     2861   &SHOULD; assume that the server will maintain a persistent connection,
     2862   even after error responses from the server.
     2863</t>
    28812864<t>
    28822865   In order to remain persistent, all messages on the connection &MUST;
     
    28842867   of the connection), as described in <xref target="message.body"/>.
    28852868</t>
    2886 </section>
    28872869
    28882870<section title="Pipelining" anchor="pipelining">
     
    29032885</t>
    29042886<t>
    2905    Clients &SHOULD-NOT; pipeline requests using non-idempotent request methods or
    2906    non-idempotent sequences of request methods (see &idempotent-methods;). Otherwise, a
    2907    premature termination of the transport connection could lead to
    2908    indeterminate results. A client wishing to send a non-idempotent
     2887   Clients &SHOULD-NOT; pipeline requests using non-idempotent request methods
     2888   or non-idempotent sequences of request methods (see &idempotent-methods;).
     2889   Otherwise, a premature termination of the transport connection could lead
     2890   to indeterminate results. A client wishing to send a non-idempotent
    29092891   request &SHOULD; wait to send that request until it has received the
    29102892   response status line for the previous request.
    2911 </t>
    2912 </section>
    2913 </section>
    2914 
    2915 <section title="Practical Considerations" anchor="persistent.practical">
    2916 <t>
    2917    Servers will usually have some time-out value beyond which they will
    2918    no longer maintain an inactive connection. Proxy servers might make
    2919    this a higher value since it is likely that the client will be making
    2920    more connections through the same server. The use of persistent
    2921    connections places no requirements on the length (or existence) of
    2922    this time-out for either the client or the server.
    2923 </t>
    2924 <t>
    2925    When a client or server wishes to time-out it &SHOULD; issue a graceful
    2926    close on the transport connection. Clients and servers &SHOULD; both
    2927    constantly watch for the other side of the transport close, and
    2928    respond to it as appropriate. If a client or server does not detect
    2929    the other side's close promptly it could cause unnecessary resource
    2930    drain on the network.
    2931 </t>
    2932 <t>
    2933    A client, server, or proxy &MAY; close the transport connection at any
    2934    time. For example, a client might have started to send a new request
    2935    at the same time that the server has decided to close the "idle"
    2936    connection. From the server's point of view, the connection is being
    2937    closed while it was idle, but from the client's point of view, a
    2938    request is in progress.
    2939 </t>
    2940 <t>
    2941    Clients (including proxies) &SHOULD; limit the number of simultaneous
    2942    connections that they maintain to a given server (including proxies).
    2943 </t>
    2944 <t>
    2945    Previous revisions of HTTP gave a specific number of connections as a
    2946    ceiling, but this was found to be impractical for many applications. As a
    2947    result, this specification does not mandate a particular maximum number of
    2948    connections, but instead encourages clients to be conservative when opening
    2949    multiple connections.
    2950 </t>
    2951 <t>
    2952    In particular, while using multiple connections avoids the "head-of-line
    2953    blocking" problem (whereby a request that takes significant server-side
    2954    processing and/or has a large payload can block subsequent requests on the
    2955    same connection), each connection used consumes server resources (sometimes
    2956    significantly), and furthermore using multiple connections can cause
    2957    undesirable side effects in congested networks.
    2958 </t>
    2959 <t>
    2960    Note that servers might reject traffic that they deem abusive, including an
    2961    excessive number of connections from a client.
    29622893</t>
    29632894</section>
     
    29792910</section>
    29802911</section>
    2981 
    2982 <section title="Message Transmission Requirements" anchor="message.transmission.requirements">
    2983 
    2984 <section title="Persistent Connections and Flow Control" anchor="persistent.flow">
     2912   
     2913<section title="Concurrency" anchor="persistent.concurrency">
     2914<t>
     2915   Clients (including proxies) &SHOULD; limit the number of simultaneous
     2916   connections that they maintain to a given server (including proxies).
     2917</t>
     2918<t>
     2919   Previous revisions of HTTP gave a specific number of connections as a
     2920   ceiling, but this was found to be impractical for many applications. As a
     2921   result, this specification does not mandate a particular maximum number of
     2922   connections, but instead encourages clients to be conservative when opening
     2923   multiple connections.
     2924</t>
     2925<t>
     2926   In particular, while using multiple connections avoids the "head-of-line
     2927   blocking" problem (whereby a request that takes significant server-side
     2928   processing and/or has a large payload can block subsequent requests on the
     2929   same connection), each connection used consumes server resources (sometimes
     2930   significantly), and furthermore using multiple connections can cause
     2931   undesirable side effects in congested networks.
     2932</t>
     2933<t>
     2934   Note that servers might reject traffic that they deem abusive, including an
     2935   excessive number of connections from a client.
     2936</t>
     2937</section>
     2938
     2939<section title="Failures and Time-outs" anchor="persistent.failures">
     2940<t>
     2941   Servers will usually have some time-out value beyond which they will
     2942   no longer maintain an inactive connection. Proxy servers might make
     2943   this a higher value since it is likely that the client will be making
     2944   more connections through the same server. The use of persistent
     2945   connections places no requirements on the length (or existence) of
     2946   this time-out for either the client or the server.
     2947</t>
     2948<t>
     2949   When a client or server wishes to time-out it &SHOULD; issue a graceful
     2950   close on the transport connection. Clients and servers &SHOULD; both
     2951   constantly watch for the other side of the transport close, and
     2952   respond to it as appropriate. If a client or server does not detect
     2953   the other side's close promptly it could cause unnecessary resource
     2954   drain on the network.
     2955</t>
     2956<t>
     2957   A client, server, or proxy &MAY; close the transport connection at any
     2958   time. For example, a client might have started to send a new request
     2959   at the same time that the server has decided to close the "idle"
     2960   connection. From the server's point of view, the connection is being
     2961   closed while it was idle, but from the client's point of view, a
     2962   request is in progress.
     2963</t>
    29852964<t>
    29862965   HTTP/1.1 servers &SHOULD; maintain persistent connections and use TCP's
     
    29892968   The latter technique can exacerbate network congestion.
    29902969</t>
    2991 </section>
    2992 
    2993 <section title="Monitoring Connections for Error Status Messages" anchor="persistent.monitor">
    29942970<t>
    29952971   An HTTP/1.1 (or later) client sending a message body &SHOULD; monitor
    29962972   the network connection for an error status code while it is transmitting
    29972973   the request. If the client sees an error status code, it &SHOULD;
    2998    immediately cease transmitting the body. If the body is being sent
    2999    using a "chunked" encoding (<xref target="transfer.codings"/>), a zero length chunk and
    3000    empty trailer &MAY; be used to prematurely mark the end of the message.
    3001    If the body was preceded by a Content-Length header field, the client &MUST;
    3002    close the connection.
    3003 </t>
     2974   immediately cease transmitting the body and close the connection.
     2975</t>
     2976</section>
     2977   
     2978<section title="Tear-down" anchor="persistent.tear-down">
     2979<t>
     2980   Persistent connections provide a mechanism by which a client and a
     2981   server can signal the close of a TCP connection. This signaling takes
     2982   place using the <x:ref>Connection</x:ref> header field
     2983   (<xref target="header.connection"/>). Once a close has been signaled, the
     2984   client &MUST-NOT; send any more requests on that
     2985   connection.
     2986</t>
     2987<t>
     2988   If either the client or the server sends the "close" option in the
     2989   <x:ref>Connection</x:ref> header field, that request/response pair
     2990   becomes the last one for the connection.
     2991</t>
     2992<t>
     2993   If the server chooses to close the connection immediately after sending the
     2994   response, it &SHOULD; send a Connection header field including the
     2995   connection option "close".
     2996</t>
     2997<t>
     2998   In case the client does not want to maintain a connection for more
     2999   than that request, it &SHOULD; send a Connection header field including the
     3000   connection option "close".
     3001</t>
     3002<t>
     3003   If the client is sending data, a server implementation using TCP
     3004   &SHOULD; be careful to ensure that the client acknowledges receipt of
     3005   the packet(s) containing the response, before the server closes the
     3006   input connection. If the client continues sending data to the server
     3007   after the close, the server's TCP stack will send a reset packet to
     3008   the client, which might erase the client's unacknowledged input buffers
     3009   before they can be read and interpreted by the HTTP application.
     3010</t>
     3011</section>
    30043012</section>
    30053013
     
    31133121  </list>
    31143122</t>
    3115 </section>
    3116 
    3117 <section title="Closing Connections on Error" anchor="closing.connections.on.error">
    3118 <t>
    3119    If the client is sending data, a server implementation using TCP
    3120    &SHOULD; be careful to ensure that the client acknowledges receipt of
    3121    the packet(s) containing the response, before the server closes the
    3122    input connection. If the client continues sending data to the server
    3123    after the close, the server's TCP stack will send a reset packet to
    3124    the client, which might erase the client's unacknowledged input buffers
    3125    before they can be read and interpreted by the HTTP application.
    3126 </t>
    3127 </section>
    3128 
    31293123</section>
    31303124
     
    48634857  Remove requirements about when servers are allowed to close connections
    48644858  prematurely.
    4865   (<xref target="persistent.practical"/>)
     4859  (<xref target="persistent.connections"/>)
    48664860</t>
    48674861<t>
    48684862  Remove requirement to retry requests under certain circumstances when the
    48694863  server prematurely closes the connection.
    4870   (<xref target="message.transmission.requirements"/>)
     4864  (<xref target="persistent.reuse"/>)
    48714865</t>
    48724866<t>
Note: See TracChangeset for help on using the changeset viewer.