On Fri, 27 Jul 2007 01:14:22 +0200, Jonas Sicking <[EMAIL PROTECTED]> wrote:
Anne van Kesteren wrote:
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?
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/>
