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
