W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

202 Accepted, Location, and Retry-After

From: James Snell <jasnell@gmail.com>
Date: Mon, 24 Oct 2011 08:54:45 -0700
Message-ID: <CABP7RbeQmXcKHcQz_zL3YLc2192cKAz7P-k5jU4D--AHQqbHKw@mail.gmail.com>
To: ietf-http-wg@w3.org, Mark Nottingham <mnot@mnot.net>, "Roy T. Fielding" <fielding@gbiv.com>
I notice that the current definition of the 202 Accepted response
still does not provide any consistent means of specifying how exactly
to go about checking the response later on... it says only, the "[t]he
representation returned with this response SHOULD include an
indication of the request's current status and either a pointer to a
status monitor or some estimate of when the user can expect the
request to be fulfilled."... which is fine in some respects but leaves
the mechanism wide open for inconsistent behavior among
implementations.

i am wondering if there is an opportunity to tighten this up a little
bit by tying in the use of the Location and Retry-After response
headers...

Essentially,

a 202 Response with a Location header would indicate that a later GET
on the Location URI would return a resource describing the current
status of the request. If the response also contains a Retry-After
header, it is specifying the minimum time that the client is being
asked to wait to expect the request to be complete. A GET on that URI
before the request is available would itself be expected to return a
202 Response.

thoughts?

- James
Received on Monday, 24 October 2011 15:55:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:49 GMT