- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Fri, 3 Feb 2017 22:03:40 -0800
- To: Tom Bergan <tombergan@chromium.org>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
> On Feb 1, 2017, at 12:41 PM, Tom Bergan <tombergan@chromium.org> wrote: > > > Applications sometimes want requests to be retried by > > infrastructure, but can't easily express them in a non-idempotent > > request (such as GET). > > nit: did you mean "in an idempotent request (such as GET)"? > > > A client SHOULD NOT automatically retry a failed automatic retry. > > Why does RFC 7230 say this? I am aware of HTTP clients that completely ignore this suggestion, and I can't offhand think of a reason why this is a good rule-of-thumb to follow. This is only referring to retries due to a dropped connection. The reason is because a second connection drop is (in almost all cases) due to the request itself, as opposed to something transient on the network path. [BTW, this doesn't refer to requests yet to be sent in a request queue or pipeline -- just the retried request in flight for which no response is received prior to FIN/RST (or equivalent).] There might be a good reason to go ahead and retry with an exponential back-off, but I don't know what that would be in general. I know lots of clients do stupid things because they are afraid of communicating server errors to their user. ....Roy
Received on Saturday, 4 February 2017 06:04:10 UTC