W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: [cors] Redirects

From: Anne van Kesteren <annevk@opera.com>
Date: Thu, 23 Apr 2009 10:54:29 +0200
To: "Jonas Sicking" <jonas@sicking.cc>
Cc: "WebApps WG" <public-webapps@w3.org>
Message-ID: <op.ust0c3t064w2qv@annevk-t60.oslo.opera.com>
On Thu, 23 Apr 2009 02:06:41 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
> So there are a few design decisions we need to make:
> Should we treat a redirect of a preflight request, as redirecting the
> actual request? The answer to this may depend on which type of
> redirect it is.
> What does a 303 redirect of a preflight request even mean. According
> to the letter of the spec you should make a GET request, but it seems
> weird to use GET request to result in a response that contains
> descriptions of capabilities.

According to the letter of the latest editor's draft this results in a  
network error.

> What level of redirects do we want to support:
> 1. Fail on all redirects.
> 2. Fail all redirects when doing preflighted requests. Both for
> preflight and actual request alike.
> 3. Only allow redirects of the request if the redirected request is
> 'safe' (i.e. would not require a preflight).
> 4. Allow all redirects of the actual request.

I want to support redirects on simple requests (as is already done for  
e.g. <img> and <form>) and preflight requests, but not on actual requests.  
This is what the specification specifies and I believe this is what WebKit  

> For the first two questions I think we should try to consult the HTTP
> spec. As I understand HTTP, the following things are true:
> * A 303 should be considered redirecting the response.

I believe 303 originally was a way to change the request method but that  
has been changed because of the obvious security flaws so now it always  
changes to GET.

> * A 307 should be considered redirecting the request and the response.
> * UAs should treat 302 as either a 303 or 307. Ideally which one
> should be decided by the user, but many UAs simply choose one or the
> other.
> * UAs are allowed to treat 301 as 302.

You're not correct about HTTP allowing what you say about 301 and 302 as  
far as I can tell, but I agree that it is what user agents do. (And I  
believe the HTTP WG has an open issue on the matter.)

> What I don't know is:
> A) How is 301 different from 302. For example can the UA cache the
> fact that a redirect is occuring in addition to treating it as a 302?


> B) If you get a 303 response from a OPTIONS request, are you allowed
> to make an OPTIONS request to the redirected URI. Would it make sense
> to?

This is not allowed by CORS.

> C) If the answer is 'no' to the question above, if you make an OPTIONS
> request to uri X, which 303 redirects to uri Y. Should the UA then
> make a GET request to uri Y and assume that the response to that
> describes the capabilities of Y? In other words, does a 303 response
> to an OPTIONS request basically mean "The resource at Y describes my
> capabilities"?

It doesn't matter, the redirect is prohibited.

> D) If you get a 307 response from an OPTIONS request to a URI, does it
> make sense to assume that a 307 would be returned for other methods,
> such as a POST, DELETE or XMYMETHOD request?

I don't understand this question. If you follow the 307 (only possible if  
it opts in itself) the final URI still has to say whether it allows  

> Without knowing the answers to these questions I am uncertain what the
> correct design is for redirects of preflighted requests.
> I think we can choose whichever level of redirect support we want in
> this version of the spec, without limiting ourselves for future
> versions. So my gut instinct right now if we just want to get the spec
> out the door is to go with level 2 as that is the simplest to spec
> while still keeping support for redirects for the most common cases.
> If we want level 3 or 4 I really think we first need to answer the
> questions A-D.

We have discussed redirects many times and the specification has been  
stable on them (apart from the minor change to preflight requests) for a  
long time. WebKit has implemented them as well now. I don't really see the  

I also note that you haven't replied to my previous emails on the subject  
where I've elaborated on pretty much the same things.

Anne van Kesteren
Received on Thursday, 23 April 2009 08:55:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:26 UTC