- From: Anne van Kesteren <annevk@opera.com>
- Date: Tue, 31 Jul 2007 15:49:01 +0200
- To: "Jonas Sicking" <jonas@sicking.cc>
- Cc: "Web APIs WG" <public-webapi@w3.org>, "Ian Hickson" <ian@hixie.ch>
On Fri, 27 Jul 2007 21:11:08 +0200, Jonas Sicking <jonas@sicking.cc> wrote: > Anne van Kesteren wrote: >> It seems nicer however to not restrict it to XMLHttpRequest and define >> the entire retrieval algorithm in the access-control specification >> including how it works for other methods and in face of redirects. > > I agree. I don't really want to hold up the [ac] spec though. At the > same time we're shipping experimental support in the next firefox alpha > release so the sooner we can get this all defined the better. I'm working on definitions for "access requests" and will put them into access-control. >> 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? -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Tuesday, 31 July 2007 13:49:26 UTC