Re: [cors] Redirects

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