Re: Protocols/APIs and redirects

On Dec 6, 2011, at 4:12 AM, Julian Reschke wrote:
> On 2011-12-06 12:56, Amos Jeffries wrote:
>> On 7/12/2011 12:14 a.m., Anne van Kesteren wrote:
>>> When we design APIs (XMLHttpRequest) and protocols (CORS) that support
>>> transparent redirects (redirects automatically followed by the API)
>>> what exactly should count as a redirect as far as they are concerned?
>>> Everything in the 3xx range that contains a Location header?
>>> E.g. for some part of CORS
>>> we explicitly fail if the response code is 301, 302, 303, or 307,
>>> because we want the ability to support transparent redirects going
>>> forward. Should we also fail if the response code is 310?
>> HTTP has always specified that any unknown code is to be treated as if
>> it was the x00 status of the matching numeric group. This has not changed.
>> For the 3xx group 300 is defined as representing any one or more
>> alternatives. If a Location header is present it is the alternative
>> location of one representation, and MAY be used for automatic redirection.
>> ...
> Well, at least for 3xx, this seems to be the worst possible choice. It makes it extremely hard to introduce any new 3xx code which is not identical to 300.

I disagree.  All 3xx codes are redirects and only some of those MAY
be followed with automatic redirection -- the ones with a Location
header field indicating the preferred redirect target.  The default
behavior applies if the recipient does not know the new code.

Extension codes will want one default behavior or the other, and
use Location accordingly.  If the client does understand the new
status code, then it will perform the process defined by that code
(which won't conflict with the default unless something invalid
is specified, like trying to reuse Location for some other purpose).

As Julian mentioned, this does not mean that XHR should automagically
follow redirects without the caller knowing the new URI -- that simply
won't work without corresponding magic content editing or a blanket
prohibition on relative references within the content.


Received on Wednesday, 7 December 2011 00:20:51 UTC