- From: James Snell <jasnell@gmail.com>
- Date: Mon, 24 Oct 2011 10:44: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>
Noted. In this case, I think the very good reason becomes obvious in that taking this approach would provide a consistent model for handling 202 Accepted responses without the extreme ambiguity that currently exists. As it stands now, there is no way that a user-agent can consistently deal with a 202 response without falling thru to specific application logic every time. At least in cases where the 202 returns both the Location and Retry-After headers, a consistent behavior can be expected and implemented. On Mon, Oct 24, 2011 at 10:34 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > On 2011-10-24 19:24, James Snell wrote: >> >> 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. >> ... > > My concern is not backwards compat, but adding special cases without a very > good reason for them. > > Best regards, Julian >
Received on Monday, 24 October 2011 17:45:19 UTC