W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

Re: #297: p1 7.2.4: retrying requests

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 25 Oct 2011 10:04:58 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <023C0A6B-555F-4677-83FE-DFD69C9D2158@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>
Works for me.


On 25/10/2011, at 3:04 AM, Julian Reschke wrote:

> On 2011-10-24 15:40, Julian Reschke wrote:
>> On 2011-07-19 15:22, Mark Nottingham wrote:
>>> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/297>
>>> 
>>> On 24/06/2011, at 4:25 PM, Mark Nottingham wrote:
>>> 
>>>> My current thinking is to life the retry-specific text out of 7.1.4
>>>> into a new section, possibly adding advice (along the lines you
>>>> mention).
>>> 
>>> I think that moving this out to a separate section is a largely
>>> editorial change. However, I feel that we should also downgrade the
>>> SHOULD to a MAY retry when the connection is closed; there isn't any
>>> reason to require a retry, and software might have good reasons not
>>> to. Also, there are a lot of implementations out there that don't retry.
>>> 
>>> Make sense?
>> 
>> Yes.
>> 
>> Make that a sibling of 7.1.4? ("Retrying Requests"?)
>> 
>>> Also...
>>> 
>>>> I'm inclined to propose removing section 7.2.4 altogether, because
>>>> it's very specific to a certain kind of request (one with a body
>>>> where the connection drops to a proxy or HTTP/1.0 server, when there
>>>> isn't an Expect: 100-continue header), and doing so can result in the
>>>> server seeing a non-idempotent request being repeated multiple times,
>>>> which is bad.
>>> 
>>> 
>>> Any objection to this?
>> 
>> No, I think it makes a lot of sense.
>> 
>> Is this something we need to mention in the "Changes from RFC 2616"
>> section, though?
>> ...
> 
> OK, proposed change attached (Trac is down):
> 
> This moves the aforementioned section into a separate subsection:
> 
> 6.1.5.  Retrying Requests
> 
>   Senders can close the transport connection at any time.  Therefore,
>   clients, servers, and proxies MUST be able to recover from
>   asynchronous close events.  Client software MAY reopen the transport
>   connection and retransmit the aborted sequence of requests without
>   user interaction so long as the request sequence is idempotent (see
>   Section 6.1.2 of [Part2]).  Non-idempotent request methods or
>   sequences MUST NOT be automatically retried, although user agents MAY
>   offer a human operator the choice of retrying the request(s).
>   Confirmation by user-agent software with semantic understanding of
>   the application MAY substitute for user confirmation.  The automatic
>   retry SHOULD NOT be repeated if the second sequence of requests
>   fails.
> 
> also it removes what was 7.2.4, and updates the Changes section to say:
> 
>   Remove hard limit of two connections per server.  Remove requirement
>   to retry a sequence of requests as long it was idempotent.
>   (Section 6.1.4)
> 
>   Remove requirement to retry requests under certain cirumstances when
>   the server prematurely closes the connection.  (Section 6.2)
> 
> Feedback appreciated,
> 
> jr
> 

Index: p1-messaging.xml
===================================================================
--- p1-messaging.xml	(revision 1452)
+++ p1-messaging.xml	(working copy)
@@ -2634,18 +2634,6 @@
    request is in progress.
 </t>
 <t>
-   This means that clients, servers, and proxies &MUST; be able to recover
-   from asynchronous close events. Client software &SHOULD; reopen the
-   transport connection and retransmit the aborted sequence of requests
-   without user interaction so long as the request sequence is
-   idempotent (see &idempotent-methods;). Non-idempotent request methods or sequences
-   &MUST-NOT; be automatically retried, although user agents &MAY; offer a
-   human operator the choice of retrying the request(s). Confirmation by
-   user-agent software with semantic understanding of the application
-   &MAY; substitute for user confirmation. The automatic retry &SHOULD-NOT; 
-   be repeated if the second sequence of requests fails.
-</t>
-<t>
    Servers &SHOULD; always respond to at least one request per connection,
    if at all possible. Servers &SHOULD-NOT;  close a connection in the
    middle of transmitting a response, unless a network or client failure
@@ -2675,8 +2663,25 @@
    excessive number of connections from a client.
 </t>
 </section>
+
+<section title="Retrying Requests" anchor="persistent.retrying.requests">
+<t>
+   Senders can close the transport connection at any time. Therefore, 
+   clients, servers, and proxies &MUST; be able to recover
+   from asynchronous close events. Client software &MAY; reopen the
+   transport connection and retransmit the aborted sequence of requests
+   without user interaction so long as the request sequence is
+   idempotent (see &idempotent-methods;). Non-idempotent request methods or sequences
+   &MUST-NOT; be automatically retried, although user agents &MAY; offer a
+   human operator the choice of retrying the request(s). Confirmation by
+   user-agent software with semantic understanding of the application
+   &MAY; substitute for user confirmation. The automatic retry &SHOULD-NOT; 
+   be repeated if the second sequence of requests fails.
+</t>
 </section>
 
+</section>
+
 <section title="Message Transmission Requirements" anchor="message.transmission.requirements">
 
 <section title="Persistent Connections and Flow Control" anchor="persistent.flow">
@@ -2812,62 +2817,8 @@
 </t>
 </section>
 
-<section title="Client Behavior if Server Prematurely Closes Connection" anchor="connection.premature">
-<t>
-   If an HTTP/1.1 client sends a request which includes a request body,
-   but which does not include an Expect header field with the
-   "100-continue" expectation, and if the client is not directly
-   connected to an HTTP/1.1 origin server, and if the client sees the
-   connection close before receiving a status line from the server, the
-   client &SHOULD; retry the request.  If the client does retry this
-   request, it &MAY; use the following "binary exponential backoff"
-   algorithm to be assured of obtaining a reliable response:
-  <list style="numbers">
-    <t>
-      Initiate a new connection to the server
-    </t>
-    <t>
-      Transmit the request-line, header fields, and the CRLF that
-      indicates the end of header fields.
-    </t>
-    <t>
-      Initialize a variable R to the estimated round-trip time to the
-         server (e.g., based on the time it took to establish the
-         connection), or to a constant value of 5 seconds if the round-trip
-         time is not available.
-    </t>
-    <t>
-       Compute T = R * (2**N), where N is the number of previous
-         retries of this request.
-    </t>
-    <t>
-       Wait either for an error response from the server, or for T
-         seconds (whichever comes first)
-    </t>
-    <t>
-       If no error response is received, after T seconds transmit the
-         body of the request.
-    </t>
-    <t>
-       If client sees that the connection is closed prematurely,
-         repeat from step 1 until the request is accepted, an error
-         response is received, or the user becomes impatient and
-         terminates the retry process.
-    </t>
-  </list>
-</t>
-<t>
-   If at any point an error status code is received, the client
-  <list style="symbols">
-      <t>&SHOULD-NOT;  continue and</t>
-
-      <t>&SHOULD; close the connection if it has not completed sending the
-        request message.</t>
-    </list>
-</t>
 </section>
 </section>
-</section>
 
 
 <section title="Miscellaneous notes that might disappear" anchor="misc">
@@ -5020,9 +4971,15 @@
 </t>
 <t>
   Remove hard limit of two connections per server.
+  Remove requirement to retry a sequence of requests as long it was idempotent.
   (<xref target="persistent.practical"/>)
 </t>
 <t>
+  Remove requirement to retry requests under certain cirumstances when the
+  server prematurely closes the connection.
+  (<xref target="message.transmission.requirements"/>)
+</t>
+<t>
   Change ABNF productions for header fields to only define the field value.
   (<xref target="header.field.definitions"/>)
 </t>
@@ -5888,6 +5845,10 @@
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/219"/>:
       "Revise Acknowledgements Sections"
     </t>
+    <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/297"/>:
+      "Retrying Requests"
+    </t>
   </list>
 </t>
 </section>


--
Mark Nottingham   http://www.mnot.net/
Received on Monday, 24 October 2011 23:05:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:49 GMT