Re: 202 Accepted, Location, and Retry-After

Agreed. The more I've thought about it tonight, the more I'm leaning
towards the use of a Link header.

On Mon, Oct 24, 2011 at 9:57 PM, Mark Nottingham <mnot@mnot.net> wrote:
> 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 05:56:57 UTC