Re: 202 Accepted, Location, and Retry-After

Hmm, I may be missing something here then... let me tease it out by
walking through a practical example... if I POST an Atom entry to a
Collection URI.. and the server returns a 202 Accepted rather than a
201 Created... what I would expect to get back as the payload of the
204 is the status monitor's representation or a URL to where I can
retrieve the status monitor's representation... that's all fine.
However, what is left entirely up to applications is how that link to
the status monitor's representation is itself represented. The data
format is entirely arbitrary. The goal of using Location in the 202
would be to provide a consistent way of referencing the status
monitors location rather than relying on arbitrary data formats.
Thinking about it further, you're right in that we could use a 303 to
point to the final response... essentially the flow would be...

  HTTP/1.1 202 Accepted
  Location: http://example.org/other-url
  Retry-After: 123

... (after 123 seconds...)

  GET /other HTTP/1.1
  Host: example.org

... (processing not yet complete)

  HTTP/1.1 202 Accepted
  Location: http://example.org/other-url
  Retry-After: 123

... (retry again after another 123 seconds)

 GET /other HTTP/1.1
 Host: example.org

... (received a redirect to the final response...)

  HTTP/1.1 303 See Other
  Location: http://example.org/final-url


Given this.. yeah, you're absolutely right, there's no need to muck
around with the Content-Location header in the 202 Response if it's
assumed that the Location header in the 202 response always points to
the status monitor, but how would I know that the 303 response is
giving me the location of the final resource rather than redirecting
to an alternative location for the final resource... at some point I'm
going to have to either be able to see a Content-Location header that
I *know* points to the final resource or have a specific response code
that says, Here it is.

Thinking about it further...as an alternative... a Web Link headers
could be used instead of Location... there is currently already a
"monitor" link relation registered within the link rel registry that
could potentially do the trick... although I'd have to review the
definition in rfc5989 to make sure)... it would essentially be,

  HTTP/1.1 202 Accepted
  Link: <http://example.org/other-url>;rel="monitor"

The fundamental flow would be the same without any need whatsoever to
muck around with the spec. Hmm...

- James



On Mon, Oct 24, 2011 at 1:00 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
> On Oct 24, 2011, at 9:13 AM, James Snell wrote:
>
>> 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.
>
> No, that is reversed -- the 202 response might be considered
> a status monitor's representation and thus point to itself using
> Content-Location.  No change to the spec is required for that
> interpretation.
>
> I don't see any need to use Location here, since 303 can be used
> to point to the final response as a placeholder.
>
> ....Roy
>
>

Received on Monday, 24 October 2011 21:04:41 UTC