- From: Close, Tyler J. <tyler.close@hp.com>
- Date: Wed, 5 Dec 2007 18:57:40 +0000
- To: "public-wsc-wg@w3.org" <public-wsc-wg@w3.org>
I've got one major comment on this proposal that I think is sufficient to send it back to the drawing board. I'll delay making more detailed comments about the proposal until I find out the answer to the major comment. A significant portion of the proposal is devoted to specifying a policy language for determining whether or not a page from a particular "root URI" should be allowed to issue a cross-domain request to a particular server. I think the problem can be solved without the server and the client software agreeing on such a policy language. For example, rather than have the server specify the rules for cross-domain requests and have the client enforce these rules, the client should simply send the request information to the server and have the server enforce its own rules. I see no advantage to placing this logic in the client, as opposed to the server. Placing the logic in the client introduces significant complexity which creates many opportunities for implementation bugs, specification ambiguity and misunderstanding by web application developers, while possibly limiting the kinds of policies a server can enforce. There is also a significant factual error in the document's Introduction: """ However, it is not possible to exchange the contents of resources or manipulate resources "cross-domain". """ It *is* possible to manipulate resources "cross-domain". An HTML page can contain a FORM which submits an HTTP request "cross-domain". Submission of this request can be automated using Javascript. The Same Origin Policy only prevents the HTML page from accessing the response to the issued request. Manipulation is allowed. Only responses are protected, not requests. --Tyler -- [1] "Access Control for Cross-site Requests" <http://www.w3.org/TR/access-control/>
Received on Wednesday, 5 December 2007 19:01:29 UTC