- From: Anne van Kesteren <annevk@opera.com>
- Date: Fri, 27 Jul 2007 11:58:02 +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 01:14:22 +0200, Jonas Sicking <jonas@sicking.cc> wrote: > Anne van Kesteren wrote: >> On Mon, 23 Jul 2007 12:37:31 +0200, Jonas Sicking <jonas@sicking.cc> >> wrote: >>> First of all I don't like that POST requests can be made unchecked to >>> any url. I do realize that this seems possible already using >>> plain/text encoded forms, but this is possibly something that browsers >>> will need to change. >> I'd be fine with giving POST the same treatment as the other methods. >> What about HEAD though? > > I talked about that with a college yesterday. The problem with HEAD is > that that would mean that the implementation would not see any PIs in > the page. Which is bad if the following PI is in there: > > <?access-control deny="*"?> Fair point. So for anything other than GET a special check will have to be done first. >>> I propose we instead specify that the DELETE request should be done to >>> the final uri of the redirects in the GET request. And if the DELETE >>> request produces any redirects then those must not be honored. >> >> I thought this is what the draft specified. > > That is not how I read the draft, but it doesn't matter, if we all think > that's a good idea then lets do that. I'll make sure this is clear. >>> Do other people have an opinion? In general it feels to me like >>> redirects and non-GET requests cross site is a rare edge-case and not >>> something that is particularly important. So we might as well do the >>> safe thing. I could even see disallowing redirects entirely, even for >>> the initial GET request. >> >> Maybe an access check should be done during each redirect as well? > > I don't think that's needed if we make the request to the final > redirected uri. Ok. >> I'm also wondering whether XMLHttpRequest-Security-Check (maybe with a >> different name) and Referer-Root (if needed) should be defined as part >> of the access-control specification. > > I don't feel strongly either way. Currently there is only one way that I > know of to make non-GET requests in a browser and try to access the > result, and that is XMLHttpRequest. Though this might change in the > future. <form method="POST" target="iframe"> is a way, but that's only for same-origin. > Actually, I wonder if XForms would be another way? Maybe, but XForms also (like HTML forms) allows for a limited set of methods. 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. 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? -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Friday, 27 July 2007 09:58:17 UTC