W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

Re: 202 Accepted, Location, and Retry-After

From: James Snell <jasnell@gmail.com>
Date: Mon, 24 Oct 2011 10:44:47 -0700
Message-ID: <CABP7RbeDOijhC4KcOLj3JZrqLvuM3hkymcVdVPA6Hc0GY-jVvg@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:26 UTC