Ignore:
Timestamp:
Oct 25, 2011, 12:31:53 AM (8 years ago)
Author:
julian.reschke@…
Message:

Remove requirement to retry in certain cirumstances, pull other instructions about retries into a separate subsection and downgrade them from SHOULD to MAY (see #297)

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r1452 r1453  
    26352635</t>
    26362636<t>
    2637    This means that clients, servers, and proxies &MUST; be able to recover
    2638    from asynchronous close events. Client software &SHOULD; reopen the
     2637   Servers &SHOULD; always respond to at least one request per connection,
     2638   if at all possible. Servers &SHOULD-NOT;  close a connection in the
     2639   middle of transmitting a response, unless a network or client failure
     2640   is suspected.
     2641</t>
     2642<t>
     2643   Clients (including proxies) &SHOULD; limit the number of simultaneous
     2644   connections that they maintain to a given server (including proxies).
     2645</t>
     2646<t>
     2647   Previous revisions of HTTP gave a specific number of connections as a
     2648   ceiling, but this was found to be impractical for many applications. As a
     2649   result, this specification does not mandate a particular maximum number of
     2650   connections, but instead encourages clients to be conservative when opening
     2651   multiple connections.
     2652</t>
     2653<t>
     2654   In particular, while using multiple connections avoids the "head-of-line
     2655   blocking" problem (whereby a request that takes significant server-side
     2656   processing and/or has a large payload can block subsequent requests on the
     2657   same connection), each connection used consumes server resources (sometimes
     2658   significantly), and furthermore using multiple connections can cause
     2659   undesirable side effects in congested networks.
     2660</t>
     2661<t>
     2662   Note that servers might reject traffic that they deem abusive, including an
     2663   excessive number of connections from a client.
     2664</t>
     2665</section>
     2666
     2667<section title="Retrying Requests" anchor="persistent.retrying.requests">
     2668<t>
     2669   Senders can close the transport connection at any time. Therefore,
     2670   clients, servers, and proxies &MUST; be able to recover
     2671   from asynchronous close events. Client software &MAY; reopen the
    26392672   transport connection and retransmit the aborted sequence of requests
    26402673   without user interaction so long as the request sequence is
    … …  
    26462679   be repeated if the second sequence of requests fails.
    26472680</t>
    2648 <t>
    2649    Servers &SHOULD; always respond to at least one request per connection,
    2650    if at all possible. Servers &SHOULD-NOT;  close a connection in the
    2651    middle of transmitting a response, unless a network or client failure
    2652    is suspected.
    2653 </t>
    2654 <t>
    2655    Clients (including proxies) &SHOULD; limit the number of simultaneous
    2656    connections that they maintain to a given server (including proxies).
    2657 </t>
    2658 <t>
    2659    Previous revisions of HTTP gave a specific number of connections as a
    2660    ceiling, but this was found to be impractical for many applications. As a
    2661    result, this specification does not mandate a particular maximum number of
    2662    connections, but instead encourages clients to be conservative when opening
    2663    multiple connections.
    2664 </t>
    2665 <t>
    2666    In particular, while using multiple connections avoids the "head-of-line
    2667    blocking" problem (whereby a request that takes significant server-side
    2668    processing and/or has a large payload can block subsequent requests on the
    2669    same connection), each connection used consumes server resources (sometimes
    2670    significantly), and furthermore using multiple connections can cause
    2671    undesirable side effects in congested networks.
    2672 </t>
    2673 <t>
    2674    Note that servers might reject traffic that they deem abusive, including an
    2675    excessive number of connections from a client.
    2676 </t>
    2677 </section>
     2681</section>
     2682
    26782683</section>
    26792684
    … …  
    28132818</section>
    28142819
    2815 <section title="Client Behavior if Server Prematurely Closes Connection" anchor="connection.premature">
    2816 <t>
    2817    If an HTTP/1.1 client sends a request which includes a request body,
    2818    but which does not include an Expect header field with the
    2819    "100-continue" expectation, and if the client is not directly
    2820    connected to an HTTP/1.1 origin server, and if the client sees the
    2821    connection close before receiving a status line from the server, the
    2822    client &SHOULD; retry the request.  If the client does retry this
    2823    request, it &MAY; use the following "binary exponential backoff"
    2824    algorithm to be assured of obtaining a reliable response:
    2825   <list style="numbers">
    2826     <t>
    2827       Initiate a new connection to the server
    2828     </t>
    2829     <t>
    2830       Transmit the request-line, header fields, and the CRLF that
    2831       indicates the end of header fields.
    2832     </t>
    2833     <t>
    2834       Initialize a variable R to the estimated round-trip time to the
    2835          server (e.g., based on the time it took to establish the
    2836          connection), or to a constant value of 5 seconds if the round-trip
    2837          time is not available.
    2838     </t>
    2839     <t>
    2840        Compute T = R * (2**N), where N is the number of previous
    2841          retries of this request.
    2842     </t>
    2843     <t>
    2844        Wait either for an error response from the server, or for T
    2845          seconds (whichever comes first)
    2846     </t>
    2847     <t>
    2848        If no error response is received, after T seconds transmit the
    2849          body of the request.
    2850     </t>
    2851     <t>
    2852        If client sees that the connection is closed prematurely,
    2853          repeat from step 1 until the request is accepted, an error
    2854          response is received, or the user becomes impatient and
    2855          terminates the retry process.
    2856     </t>
    2857   </list>
    2858 </t>
    2859 <t>
    2860    If at any point an error status code is received, the client
    2861   <list style="symbols">
    2862       <t>&SHOULD-NOT;  continue and</t>
    2863 
    2864       <t>&SHOULD; close the connection if it has not completed sending the
    2865         request message.</t>
    2866     </list>
    2867 </t>
    2868 </section>
    28692820</section>
    28702821</section>
    … …  
    50214972<t>
    50224973  Remove hard limit of two connections per server.
     4974  Remove requirement to retry a sequence of requests as long it was idempotent.
    50234975  (<xref target="persistent.practical"/>)
     4976</t>
     4977<t>
     4978  Remove requirement to retry requests under certain cirumstances when the
     4979  server prematurely closes the connection.
     4980  (<xref target="message.transmission.requirements"/>)
    50244981</t>
    50254982<t>
    … …  
    58895846      "Revise Acknowledgements Sections"
    58905847    </t>
     5848    <t>
     5849      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/297"/>:
     5850      "Retrying Requests"
     5851    </t>
    58915852  </list>
    58925853</t>
Note: See TracChangeset for help on using the changeset viewer.