- 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>
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 http://annevankesteren.nl/
Received on Thursday, 13 August 2009 18:35:22 UTC