- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 26 Aug 2011 09:48:33 +0200
- To: Mark Nottingham <mnot@mnot.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
On 2011-08-26 02:35, Mark Nottingham wrote: > > 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. Right. I'm just not sure which of these makes more sense, so before picking one we probably should look at existing usage. > ... Best regards, Julian
Received on Friday, 26 August 2011 07:49:09 UTC