- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 13 Aug 2009 13:27:36 -0700
- 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 UTC