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

Re: [File API] events vs callbacks

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 13 Aug 2009 13:27:36 -0700
Message-ID: <63df84f0908131327l7a428c00g58e8ce2e66b28637@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: Olli Pettay <Olli.Pettay@helsinki.fi>, arun@mozilla.com, Web Applications Working Group WG <public-webapps@w3.org>
On Thu, Aug 13, 2009 at 11:33 AM, Anne van Kesteren<annevk@opera.com> wrote:
> 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 means that we can't assume that headers and request methods etc is
supported by the protocol.

>>> 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.

The actual *url* can't ever have the same origin, at least not in the
mozilla implementation, since the url is of a different scheme.
However the security context (principal in mozilla terms) of the
loaded resource can be same origin since we set the security context
to be that of the loading page.

However I guess the same is true for filedata:, so we would have to
add some sort of exception there in the implementation. I still don't
see a reason not to do that given that it's nice to have a consistent
API for developers.

>> 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.

Given that it can't be tested, I'm not sure how we would specify it.

/ Jonas
Received on Thursday, 13 August 2009 20:28:37 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT