- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 26 Aug 2011 10:35:33 +1000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 25/08/2011, at 6:13 PM, Julian Reschke wrote: >> The 202 Accepted status code has come up from time to time, with people liking the idea behind it, but needing a bit more. >> >> <http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-15#section-8.2.3> >> >> I'm wondering if we can clarify things a little bit by adding two bits of text: >> >> --8<--- >> A 202 response MAY carry a Retry-After header field that indicates an estimation of when the processing might be complete. >> >> It MAY also carry a Location header that indicates the URI of a resource that will be created once processing has completed. >> --->8--- >> >> Thoughts? > > Nit: do not use MAY here, just state that the header fields are applicable. Agreed. > Other than that - the current description says: > > "The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The 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." > > ...so a "status monitor" resource would also be a candidate for the Location header field. If it could be either, I think that would be bad for interop; you wouldn't be sure what following the location would result in. > Maybe this is premature? Does anybody use this right now? I've seen a number of people ask for it explicitly, and I don't think we're getting too far in front by just mentioning what can already occur. Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Friday, 26 August 2011 00:36:12 UTC