Re: #297: p1 7.2.4: retrying requests

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