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  
implements.


> 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?

Yes.


> 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  
POST/DELETE/XMYMETHOD.


> 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  
problem.

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
http://annevankesteren.nl/
Received on Thursday, 23 April 2009 08:55:12 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT