Re: Comments on: Access Control for Cross-site Requests

Close, Tyler J. wrote:
> 
> Ian Hickson wrote:
>> On Thu, 3 Jan 2008, Close, Tyler J. wrote:
>>> So what exactly do you guys mean by: "the author does not have the
>>> access (or ability) to configure the server or write cgi
>> scripts"? How
>>> do I put an "Access-Control" HTTP header on a non-XML file
>> if I can't
>>> configure the server in any way? If this cannot be done,
>> does this mean
>>> that the current proposal does not support cross-domain
>> JSON for this
>>> deployment scenario?
>> Yes; the proposal is primarily intended for XML. The HTTP
>> header was added
>> later as a way to allow non-XML files to be used as well, but
>> it wasn't
>> part of the initial design or intent.
> 
> Wow. OK, that explains how policy enforcement ended up on the client.
 > It seems like a perverse outcome in the absence of this information.
 > I still think it's a bad idea to take on all this complexity for the
 > benefit of one Content-Type in a rather narrow deployment scenario.

Also note that it is very possible to add in-file support for other 
formats in the future. For example it would be very doable to add 
support for static JSON files by defining a way to put the 
access-control information above the JSON data:

example.org/myjson.js:
/* access-control: allow <*> deny <evil.com> */
{ firstName: "john", lastName: "smith" }

This is not a propsal, and I'm sure we'd need to make it slightly more 
complicated, but you get the idea. We could possibly even define a 
generic container format, for example using multipart mime, that could 
then contain any file type.

However, this is something I'd rather do in a following version of the 
access-control spec given how far along we already are with the current 
spec.

/ Jonas

Received on Thursday, 3 January 2008 17:07:43 UTC