Re: NEW ISSUE(S): Retrying Requests

Brian Smith wrote:
> I agree that is a good idea. It also affects the Pipelining section, and
> anywhere else that mentions idempotency. With this new section, maybe
> the term idempotency can be totally removed from the specification? I
> agree with Roy [1] that the use of the term in RFC 2616 has caused more
> trouble than benefit.
> 
> [1] http://www.imc.org/atom-protocol/mail-archive/msg10759.html

I'm still puzzled as to when a client should reuse a persistent
connection for requests that (it knows) shouldn't be retried.

Since all servers close a persistent connection an unspecified time
after the first request, and that's perfectly healthy (all servers
must do it), how long since it saw activity should a client wait
before considering the connection unsafe for those type of requests?

E.g. if a server closes idle connections after 60 seconds, and a
client transmits a request 58 seconds after the previous response,
there's a good chance the client will get a connection error.

If the error is due to perfectly healthy idle connection shutdown by
the server, the client should retry automatically no matter what type
of request (ideally).  That is expected in ordinary circumstances; no
real errors have occurred.

But if it's due to a fault (such as the server crashed), although it
might retry, sometimes it shouldn't be automatic, and definitely not
for some kinds of request.  Ideally, it would be reported as a fault.

This works fine, as long as the client has a cut-off time somewhat
lower than the server's idle shutdown time.

So to make this reliable, is there a recommended cut-off time for
clients and an idle shutdown time for servers?  Or is this left to
implementors to look at each others code, and pick a value that
matches what they think the other end does?

-- Jamie

Received on Thursday, 6 March 2008 00:33:56 UTC