HTTP/1.1 - Retry-after for 3xx as well as 503?

At the HTTP WG at Memphis I was asked to explain why I proposed this (see
original quoted at end).

>- push caching
This was described in an excellent poster at WWW5 in Paris. With Netscape's
305/306 Use Proxy proposal Retry-after: would allow the server some time
(based on Content-length?) to push the content to a proxy if it needed
updating (which the server is best placed to know) before re-directing to
the proxy.

>- switching to deferred (poss. multicast) transport (e.g. SMTP) under
heavy server load
I was thinking here of the server protecting itself from overload (e.g.
during flash crowds) by sending to a mailing list arranged to get the
content out to localised mail archives. It could redirect different clients
to pick up different URLs (posting ids) from their nearest archive (based
on some CGI with a rule set for allocating different ranges of client
addresses to different archives). This would require the re-direct to be
deferred, hence the need for Retry-after:
As a second idea, say for instance, congestion control for reliable
multicast gets sorted out in the next year. Then to prevent the "flash
crowd" problem, you might want to re-direct all requests in time to
staggercasts of the content by specifying how long until the next scheduled
push. The URL re-directed to would obviously be of a URL scheme which
identified it as a multicast which didn't need another request.

I have no intention of implementing this, so take it as an idea. If an
implementer wants to pick it up... great.

I just thought the sording of the Retry-after: header section in the spec.
was overly restrictive in defining the semantics just for one class of
deferred client access (503) when there was a whole potential other class
(3xx).

I would suggest it is a SHOULD which allows people to leave it out if they
have good reason, but as I say, I can't see it's difficult to implement in
a browser at all.
A compromise might be to make this a MAY.

Bob

>Date: Tue, 04 Mar 1997 17:02:19 +0100
>To: http-wg@cuckoo.hpl.hp.com
>From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
>Subject: HTTP/1.1 - Retry-after for 3xx as well as 503?
>
>Issue for HTTP/1.1 before becomes draft standard?...
>
>It would be a simple change to the spec. and fairly tidy to implement in a
browser to make it clear that the Retry-After header should apply to:
>- 3xx Redirect class responses
>- as well as 503 Service Unavailable
>
>This would make it much easier to implement versions of
>- push caching
>- switching to deferred (poss. multicast) transport (e.g. SMTP) under
heavy server load
>- etc.
>
>Bob
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/

Received on Thursday, 10 April 1997 00:38:12 UTC