Re: 202 Accepted, Location, and Retry-After

I'm -1 on this approach; it doesn't make sense for a Location on a 201 to mean "there's the thing I created" while on a 202 it means "here's a status monitor for this resource."

201 + Location is a well-understood pattern, and the semantics translate well to 202.

Furthermore, Content-Location has very specific semantics on a response; you can't just repurpose them. Use a link relation instead.

Cheers,



On 25/10/2011, at 3:13 AM, James Snell wrote:

> Julian, thank you for the pointer, I had missed that thread entirely.
> The distinction between the final response and the status monitor
> concern could be addressed through the additional application of the
> Content-Location header. Within a 202 Response, the Location URI would
> be assumed to point essentially to a status monitor, while the
> Content-Location would point to the URI of the final response. If they
> happen to point to the same URI, then all is still good... otherwise,
> the distinction between the two URIs is clear and things are still
> good. Should the Content-Location header be omitted, the server is
> being purposefully non-committal and is effectively requiring the
> user-agent to issue a request to the Location URI to discovery any
> further information about the status of the request and the final
> response. Should a GET to the Location URI return a 202 response
> indicating that the request is not yet complete, it too can contain
> both the Location and Content-Location headers. That would seem to me
> to effectively clear up any possible confusion that could arise.
> 
> On Mon, Oct 24, 2011 at 9:01 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
>> 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
>> <http://lists.w3.org/Archives/Public/ietf-http-wg/2011JulSep/0343.html>.
>> 
>> 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
>> 
>> 
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Tuesday, 25 October 2011 04:57:50 UTC