Re: #297: p1 7.2.4: retrying requests

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
> 

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