- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 31 Jul 2007 16:01:55 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Web APIs WG <public-webapi@w3.org>, Ian Hickson <ian@hixie.ch>
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
Received on Wednesday, 1 August 2007 01:31:55 UTC