Re: 202 Accepted, Location, and Retry-After

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:02:03 UTC