Subject: Re: #297: p1 7.2.4: retrying requests

From: Julian Reschke <[email-masked]>
Date: Mon, 24 Oct 2011 15:40:40 +0200

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?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 24 Oct 2011 18:04:45 +0200

On 2011-10-24 15:40, Julian Reschke 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.
>
>>> 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?
>
> ...

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>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 25 Oct 2011 10:04:58 +1100

Works for me.

Index: p1-messaging.xml
 
+</section>
+

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Oct 2011 09:33:29 +0200

> Works for me.

-> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1453>