- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 26 Jul 2007 16:14:22 -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: > > 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="*"?> >> Second, I'm a little bit worried about the algorithm used to for >> non-GET (non-POST in the current draft) in connection with redirects. >> From my understanding the following is a valid scenario: >> >> 1. Web page on server A makes a DELETE request to server B >> 2. XHR implementation sends a GET request to server B >> 3. Server B redirects to server C >> 4. Server C sends reply that approves the request using appropriate >> headers and an "Allow: DELETE" header >> 5. XHR implementation sends DELETE request to server B > > Why not directly to server C? > > >> 6. Server B deletes file on requested uri. >> >> [...] >> >> 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. >> 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. > 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. Actually, I wonder if XForms would be another way? / Jonas
Received on Thursday, 26 July 2007 23:15:10 UTC