- From: Mark Nottingham <mnot@yahoo-inc.com>
- Date: Thu, 3 Jan 2008 13:39:09 +1100
- To: "Close, Tyler J." <tyler.close@hp.com>
- Cc: Ian Hickson <ian@hixie.ch>, Anne van Kesteren <annevk@opera.com>, "public-appformats@w3.org" <public-appformats@w3.org>
On 03/01/2008, at 1:17 PM, Close, Tyler J. wrote: Hey, > The above comment leaves me with the impression that you too think > the client should be enforcing the server's access control policy. I > just find this a really strange position. Ian seems to support this > view with the perspective that client developers will deploy better > software faster than server developers. Is that also your rationale? > > Please keep in mind that a positive response to the GET request of > step 2 just means that the server admin is saying: "Yes, I've setup > some server-side software to control cross-domain requests". It > doesn't mean: "I'm blindly letting through all cross-domain > requests, my users be damned!", as some seem to be implying. My concern was that it's quite binary; if it's on, the server is required to check the Referer-Root for *every* resource on it, even if it only wants to enable one resource for cross-domain access. That's a pretty high bar in some environments. That having been said, I imagine it would be easy enough to come up with an Apache or IIS module to enforce a policy in some XML format. I don't buy into Ian's argument that it needs to be deployable without server-side changes at all; if people are motivated to allow cross- site requests, checking a header isn't a big deal. It's easy enough to do with rewrite rules if you need to, and many, many cheap Web hosts offer access to those. So, I'll retract that comment. Cheers, -- Mark Nottingham mnot@yahoo-inc.com
Received on Thursday, 3 January 2008 02:39:51 UTC