- From: James Snell <jasnell@gmail.com>
- Date: Mon, 24 Oct 2011 08:54:45 -0700
- To: ietf-http-wg@w3.org, Mark Nottingham <mnot@mnot.net>, "Roy T. Fielding" <fielding@gbiv.com>
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? - James
Received on Monday, 24 October 2011 15:55:20 UTC