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

Re: Protocols/APIs and redirects

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Wed, 07 Dec 2011 00:56:14 +1300
Message-ID: <4EDE02DE.5060006@treenet.co.nz>
To: ietf-http-wg@w3.org
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 
> http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#actual-request 
> 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.
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-17#section-7.3.1

AYJ

>
> Should 
> http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#same-origin-request-event-rules 
> follow redirects for status codes other than 301, 302, 303, and 307? 
> Should it instead treat anything else as a network error so we can 
> more easily extend it in the future? If we do not treat it as a 
> network error the developer would just get back a response with a 
> status code of 310 and the Location header and going forward we could 
> never treat it as any of the "blessed redirects" anymore.
>
>
> Aside: What happened to 
> http://lists.w3.org/Archives/Public/ietf-http-wg/2011JulSep/0014.html 
> ? I could not find the issue.
>
>
Received on Tuesday, 6 December 2011 11:57:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:50 GMT