W3C home > Mailing lists > Public > public-appformats@w3.org > January 2008

RE: ISSUE-18: Is JSONRequest an acceptable alternative to the current model? [Access Control]

From: Close, Tyler J. <tyler.close@hp.com>
Date: Fri, 4 Jan 2008 22:25:26 +0000
To: Anne van Kesteren <annevk@opera.com>, Web Application Formats Working Group WG <public-appformats@w3.org>
Message-ID: <C7B67062D31B9E459128006BAAD0DC3D144B3CC6@G6W0269.americas.hpqcorp.net>

Anne van Kesteren:
> On Fri, 04 Jan 2008 13:57:33 +0100, Web Application Formats
> Working Group
> Issue Tracker <sysbot+tracker@w3.org> wrote:
> > ISSUE-18: Is JSONRequest an acceptable alternative to the current
> > model?  [Access Control]
> No, it's not. JSONRequest does not work for the following reasons (not
> exhaustive):
> * It doesn't work for XML formats, such as XBL and XSLT. XML
> formats and
> particularly <?access-control? are one of the main use cases of this
> specification as originally designed.
> * It requires a new JavaScript network API that only allows
> the transport
> of JSON. We already have a JavaScript network API that covers
> more than
> JSON (simply uses HTTP) -- XMLHttpRequest.

So, strictly speaking, the above is not true. It is not possible to simply place a JSON file on a server and in so doing make it available for cross-domain requests using the proposed XMLHttpRequest extension. I believe that this WG has stated that this minimal level of control over the server is one of the required deployment scenarios; but that functionality is only supported for XML. Similarly, the JSONRequest proposal only supports this functionality for JSON. Both proposals can tunnel other Content-Types within their supported Content-Type.

> * Having multiple network APIs seems like a bad idea.

The two proposals have made opposite choices on fundamental design decisions, such as: where policy is enforced, whether or not cookies are sent, and whether or not interoperation with existing resources is supported. Any one of these choices could prove significant to adoption. For example, some developers may require better support for other Content-Types; whereas some organizations may be reticent to allow installation of browsers that may interoperate with existing web resources in unanticipated ways.

I would prefer to have a simple design that supports all Content-Types; but failing that, I want to at least get some cross-domain request support. I think there is some risk the XMLHttpRequest proposal could encounter resistance, due to its different design choices. The JSONRequest proposal seems like a good fallback position. I think it would be wise to additionally encourage adoption of the JSONRequest proposal. It's a small complexity increment that provides useful insurance against failure of the XMLHttpRequest proposal. Remember, it's not enough to get the code into the browsers; you also have to convince IT departments that they should install it with the feature turned on by default, and then leave it on as bug reports start to come out.


[1] "Access Control for Cross-site Requests"
Received on Friday, 4 January 2008 22:27:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:56:21 UTC