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