W3C home > Mailing lists > Public > public-webapi@w3.org > October 2007

Re: XHR data: and javascript: requests (was: Re: XHR: definition of same-origin)

From: Mark Baker <distobj@acm.org>
Date: Tue, 2 Oct 2007 12:53:58 -0400
Message-ID: <e9dffd640710020953l3ba3af60sfdbdca49b30c720a@mail.gmail.com>
To: "Anne van Kesteren" <annevk@opera.com>
Cc: "Web API WG (public)" <public-webapi@w3.org>

On 10/2/07, Anne van Kesteren <annevk@opera.com> wrote:
> On Tue, 25 Sep 2007 14:52:17 +0200, Anne van Kesteren <annevk@opera.com>
> wrote:
> > It would be nice to get some implementation feedback on what to do about
> > data:, javascript: etc.
> Determining the origin of data:, javascript: URIs when they are
> responsible for making the request is defined by HTML5, but it's not
> really clear to me what should happen when somebody does:
>  1. client.open("data:...")
>  2. client.open("javascript:...")
> should that always work or always throw? Testing shows that browsers throw
> (Firefox, Internet Explorer, Opera), except that Opera allows access to
> data:. The simplest thing to do would be to disallow everything that does
> not have any of the scheme, ihost or port components, but I'm open to
> other suggestions.

Opera's behaviour sounds sensible.  I'd throw on javascript: because
the embedded script could do arbitrary things, whereas the calling
script presumably expects open() to have predictable side effects.

I suppose that a data:text/javascript,... URI should also throw if it
the agent would otherwise execute the embedded script.  But I see no
harm in permitting any other non-executable-content data: URIs to be

Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com
Received on Tuesday, 2 October 2007 16:54:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:24 UTC