Anne van Kesteren:
> On Fri, 04 Jan 2008 13:57:33 +0100, Web Application Formats
> Working Group
> Issue Tracker <[EMAIL PROTECTED]> 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.
--Tyler
--
[1] "Access Control for Cross-site Requests"
<http://www.w3.org/TR/access-control/>
