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

Re: 202 Accepted, Location, and Retry-After

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 24 Oct 2011 18:01:18 +0200
Message-ID: <4EA58BCE.4040004@gmx.de>
To: James Snell <jasnell@gmail.com>
CC: ietf-http-wg@w3.org, Mark Nottingham <mnot@mnot.net>, "Roy T. Fielding" <fielding@gbiv.com>
On 2011-10-24 17:54, James Snell wrote:
> 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?

See thread starting at 

My concern was that there are *two* obvious ways to use Location, (1) 
for the final response, (2) for a status monitor. We should research 
what's in use right now, but haven't done so properly yet.

Best regards, Julian
Received on Monday, 24 October 2011 16:02:03 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:26 UTC