W3C home > Mailing lists > Public > public-webapi@w3.org > July 2007

Re: [xhr2] cross site non-GET requests and redirects

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>
Message-ID: <op.tv4ba0a364w2qv@annevk-t60.oslo.opera.com>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:58 GMT