W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

automatic retrying of requests

From: Life is hard... and then you die. <Ronald.Tschalaer@psi.ch>
Date: Sun, 21 Jul 1996 03:13:51 +0200
Message-Id: <96072103135160@psicla.psi.ch>
To: HTTP-WG%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1150

  While trying to implement persistent connections in a client I've run
into a small question concerning the automatic retrying of requests
(this is based on draft-ietf-http-v11-spec-06, section 8). Basically
the question I'm asking myself is 'how often should/may I automatically
retry the request if it keeps failing due to a network error'. My
uncertainty stems from the following parts in the spec:

page 44, top, in the context of asynchronous close events, says

> However, this automatic retry SHOULD NOT be repeated if the second
> request fails.

I assume that 'fails' refers to a network error, and not to a returned
status code >= 400? So this says a given request should be retried at
most once.

But then, on page 45, an algorithm is presented for HTTP/1.0 persistent
connections that basically says 'retry until you get a valid status
(success or error) or the user aborts the process'. Isn't this in
conflict with page 44, as it implies you should automatically retry
as often as necessary?

Furthermore for HTTP/1.1 the last paragraph in section 8, page 46, says

> An HTTP/1.1 (or later) client that sees the connection close after
> receiving a 100 (Continue) but before receiving any other status SHOULD
> retry the request, and need not wait for 100 (Continue) response (but
> MAY do so if this simplifies the implementation).

I assume this is only talking about the first attempt to send a request,
and does not hold for retries? Otherwise it would again be in conflict
with page 44.


Received on Saturday, 20 July 1996 18:21:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC