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/>