- From: James Snell <jasnell@gmail.com>
- Date: Mon, 24 Oct 2011 09:41:47 -0700
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: ietf-http-wg@w3.org, Mark Nottingham <mnot@mnot.net>, "Roy T. Fielding" <fielding@gbiv.com>
That would be necessary, yes. A Content-Location in a 202 Response would necessarily point to the expected final resource and would not be representative of the 202 responses own payload, which, by definition of the 202 code is supposed to describe the status of the request. A description of the relationship between the Location, Content-Location and Retry-After headers within a 202 response would also need to be added. On Mon, Oct 24, 2011 at 9:24 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > On 2011-10-24 18:13, 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. If they > >> ... > > In which case we'd need to special-case status code 202 within > <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#identifying.response.associated.with.representation>, > right? > >> ... > > Best regards, Julian >
Received on Monday, 24 October 2011 16:42:15 UTC