- From: Close, Tyler J. <tyler.close@hp.com>
- Date: Thu, 3 Jan 2008 01:56:57 +0000
- To: Ian Hickson <ian@hixie.ch>
- CC: Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@opera.com>, "public-appformats@w3.org" <public-appformats@w3.org>
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. > (Having said that, it's also a lot easier to add a single > HTTP header than > it is to add CGI scripts or magic files in specific > locations, let alone > scripts that respond to OPTIONS, and that itself is still far > easier than > upgrading the entire server.) OK, so list the server-side technologies I'm allowed to use and I'll see if I can safely allow cross-domain access without communicating the access policy to the client. (I still doubt the utility of these constraints, but whatever, I'll play) --Tyler
Received on Thursday, 3 January 2008 01:58:47 UTC