On Mon, 23 Jul 2007 12:37:31 +0200, Jonas Sicking <[EMAIL PROTECTED]> 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?
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.
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'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.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
