Re: 202 Accepted, Location, and Retry-After

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
>
>

Received on Monday, 24 October 2011 16:13:45 UTC