Re: Extension methods & XMLHttpRequest

Am 11.06.2006 um 15:29 schrieb Bjoern Hoehrmann:

>
> * Jamie Lokier wrote:
>> Are you sure it's possible to introduce new methods that have similar
>> problems to TRACE and CONNECT?
>
> Of course it is. There may be problems, but it certainly is possible.
>
>> Relax XMLHttpRequest's constraints slightly to allow GET (only)
>> requests to any domain, with the constraint that in this case it's  
>> not
>> permitted to set arbitrary request headers or read most of the
>> response headers.  (Reading "Content-Type" should be allowed).
>
> Well, A is your client with a fixed IP, B grants access to A but no
> one else, C wants data from B. To achieve that, you simply have to be
> tricked into visiting a page on C, which is rather trivial. The only
> way to prevent that is to deny (indirect) read access from C to A.
>
> http://lists.w3.org/Archives/Public/public-webapi/2006Jun/0012 and
> http://www.w3.org/TR/access-control/ might be interesting to you.

Help me understand: The use cases for a more open XHR are motivated  
by application/server developers, right? Reading the above piece  
about access-control, it appears to me that it would not be an  
obstacle to implement something at the server side.

What I mean is that XHR would have the following behavior:
- Implement a "whitelist" of methods and uses which are known to be  
"safe"
- For all methods outside of this, let XHR ask the server if it ok.  
For example, let XHR send an OPTION request and look for an XHR-Allow  
header, listing the methods allowed to XHR. (or whatever, the key is  
that the server is in control)

Seems to me that this approach puts server application developers in  
the driver seat and lets browser developers stay safe by default, no  
matter what future http will bring.

//Stefan

Received on Monday, 12 June 2006 07:53:36 UTC