Re: 202 Accepted, Location, and Retry-After

Ordinarily I would agree but, in this case, I'm not convinced that the
backwards compatibility problem is a significant issue. Specifically,
I have not seen (and did not see anything in the examples linked to
within the other thread) any existing cases of 202 that would conflict
with this approach. Should the Content-Location header be excluded
from the 202 response, it would simply be handled as it is today.
Currently, the use of Content-Location in a 202 is rather undefined
and left wide open to interpretation so there's really no solid
precedent to fall back on or conflict with, it would seem.

On Mon, Oct 24, 2011 at 9:49 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 2011-10-24 18:41, James Snell wrote:
>>
>> 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.
>> ...
>
> There you go. The fact that we need to introduce a new special-case without
> any backwards compat we need to consider makes me very unhappy.
>
> I believe the right thing to do here is to write all of this down as a
> distinct draft, and leverage link relations to identify one of the two
> related resources (or even both).
>
> Best regards, Julian
>

Received on Monday, 24 October 2011 17:25:13 UTC