Anne van Kesteren wrote:
By the way, a request to a same-origin redirect that redirects to a
non same-origin resource should also work I suppose? Or is there some
reason you need to know in advance you're going to make a non
same-origin request?
For GET requests I don't see a reason to not allow redirects from
same-origin to another server.
For POST and other methods it is a bit more complicated since you at
the point of the redirect have to switch to sending out a GET requests
first to make sure that the POST is safe. At least in mozilla we can't
stall the redirect while waiting for the GET to finish. It is probably
possible though to cancel the initial request, fire the GET request,
and then perform the redirect. Would be good to get other implementors
input on this.
Also, what happens for same-origin which redirects to non same-origin
which redirects to same-origin again. Do you perform an access check?
In the implementation I've written, the decision weather to check access
control headers is done by comparing the final uri with the requesting
uri. So if you're redirected back to the original server no
access-control check is done.
I'd be all ears if someone think we should do checks as soon as a
request has passed another domain at some point.
/ Jonas
