W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: [File API] events vs callbacks

From: Anne van Kesteren <annevk@opera.com>
Date: Thu, 13 Aug 2009 20:33:59 +0200
To: "Jonas Sicking" <jonas@sicking.cc>
Cc: "Olli Pettay" <Olli.Pettay@helsinki.fi>, arun@mozilla.com, "Web Applications Working Group WG" <public-webapps@w3.org>
Message-ID: <op.uyl5uxhj64w2qv@annevk-t60>
On Thu, 13 Aug 2009 19:24:30 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
> Does this match implementations? I'm pretty sure that mozilla's
> implementation supports reading from ftp (as long as it's same-origin
> with the page making the request). Is that not the case with other
> implementations?

Ah, did not think about ftp and have not checked. Whatever is being done for ftp should be of little relevance though, I think.

>> It is what we already do for e.g. "data", "mailto", and "javascript".  
>> Although the specification should be more clear on that.
> data: and javascript: are somewhat special case in gecko, since a page
> can never have a "data:" or "javascript:" origin. Thus those *urls*
> are always a different origin.

I do not think that is the case anymore per HTML5 (a data URL can have the same origin as a http URL under certain circumstances), but regardless I do not think it is worth making them work for XMLHttpRequest.

> mailto:, tel:, aim:, telnet:, shell:, are the same, no page will ever
> be same origin as a url with those schemes.
> Additionally gecko has a block that prevents you from using schemes
> that don't return data in situations where not returning data doesn't
> make any sense. So for example you can't do <img src="tel:...">, or
> <link rel=stylesheet href="mailto:..." >

That makes sense. I wonder if we should make that more explicit somehow.

Anne van Kesteren
Received on Thursday, 13 August 2009 18:35:22 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:18 UTC