- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 13 May 2009 18:24:05 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: WebApps WG <public-webapps@w3.org>
Ok, so here is how I understand how we arrived at the current design: 1. The reason that 303 is explicitly called out as disabled for all types of requests is that there is an assumption that browsers change OPTIONS requests into GET requests for a 303 redirect, but not for other types of redirects. 2. There is a desire to supply a redirection mechanism for CORS requests that allows an HTTP API living on one URI to be moved to another URI. 3. It is *not* deemed important to support other types of redirects, even if such redirects are commonly used today. Is this correct? So my testing[1] shows that 1 is only true for IE. Here is what I got for redirects of OPTIONS requests in various browsers: IE 8 301:OPTIONS, 302:OPTIONS, 303:GET, 307:OPTIONS Firefox 3.5 301:GET, 302:GET, 303:GET, 307:OPTIONS Safari 3.2 301:GET, 302:GET, 303:GET, 307:GET Opera 9.5 Wasn't able to make any OPTIONS requests at all. Chrome 2.0 301:GET, 302:GET, 303:GET, 307:OPTIONS And here is what I got for POST requests IE 8 301:GET, 302:GET, 303:GET, 307:POST Firefox 3.5 301:GET, 302:GET, 303:GET, 307:POST (sometimes need user confirmation) Safari 3.2 301:GET, 302:GET, 303:GET, 307:GET Opera 9.5 301:GET, 302:GET, 303:GET, 307:GET or POST depending on user choice. Chrome 2.0 301:GET, 302:GET, 303:GET, 307:POST Based on this I don't think it makes sense to call out 303 redirects explicitly. It seems much more common for UAs to treat 303 like a 301/302 than anything else (there's only one exception in the above tables). While I do agree that 2 is something that we want, I am not sure the current solution is a great one. The current design uses the HTTP redirects to redirect a CORS request. This seems to me very much like we are abusing a HTTP redirect to mean something other than what HTTP spec says it means. This seems very similar as the situation for caching of preflight requests. Here we decided not to use the standard http headers since that would be abusing the semantic meaning of those headers. Instead we invented our own access-control-max-age header. If we are sticking with the current solution in the spec I definitely think we should point out this aspect to the HTTP group. Regarding 3, I'm wondering how we came to that conclusion? Given how poorly API redirections work (307s gives horribly user UI in firefox and opera, and I *think* in older versions of IE), I suspect those types of redirects are not very commonly in use today. Non-307 redirects are not useful for the types of requests that require preflights since they turn into GET requests and loose their request body. However 302 redirects of POSTs I know are used since they are used to prevent ugly 'you have to reload to show this page' pages in browsers. In other words, the site lets one uri receive the POST request, but serve the response from another uri using a 302 redirect. So is there a reason why we think API redirects are more important for CORS requests, than for requests that are used on the web today? Including cross site <form> POSTs. Based on all of the above, my recommendation is this: Remove the special case for 303 redirects. Either remove all support for redirects of preflighted requests. Or require a 307 redirect since that is what makes most sense for OPTIONS requests, and also is the redirect type that most closely matches the type of redirect that we are performing here. And even if so explicitly tell the HTTP bis WG to review this mechanism. Either remove support for all redirects of preflighted requests, or allow 301/302/303 redirects of the response from a preflighted request. / Jonas [1] http://people.mozilla.org/~sicking/ac/redirres.html
Received on Thursday, 14 May 2009 01:25:01 UTC