W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

Re: [whatwg] XML data islands related question

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 8 Aug 2013 18:57:39 +0000 (UTC)
To: "Jukka K. Korpela" <jkorpela@cs.tut.fi>
Message-ID: <alpine.DEB.2.00.1308081853260.27623@ps20323.dreamhostps.com>
Cc: whatwg <whatwg@lists.whatwg.org>
On Thu, 8 Aug 2013, Jukka K. Korpela wrote:
> 2013-08-08 9:13, Ian Hickson wrote:
> > 
> > XHR uses the same underlying logic as <img src=""> and <script 
> > src="">. If you're able to conjur a file up for <img src=""> or 
> > <script src="">, then I don't see why you wouldn't be able to conjur 
> > it up for XHR.
> 
> When a local HTML file is opened in a browser and it accesses local 
> files, with simple relative URLs like "foo.png" or "bar.js", <img 
> src=""> and <script src=""> do not cause HTTP requests of any kind.

Nor would XMLHttpRequest. XHR has nothing to do with XML, or HTTP, or, 
really, any particular thing to do with requests. It's just a way to do a 
fetch (or, these days, a CORS fetch).


> > Could you elaborate on exactly what you mean by "truly local HTML5 
> > application"?
> 
> At the simplest case, it is a set of files (HTML, CSS, JavaScript, image 
> files), and launching the application means opening the HTML file in a 
> browser, or in a sufficiently browser-like program. Conceptually, this 
> would work even if the Internet didnít exist. In practice, such 
> applications are often distributed via web servers, and they may have 
> URLs, but they can also be distributed on different media offline.

Whatever they're served from, if they're loaded in a browser, they have a 
URL. It could be an http: URL or a file: URL, but it's still a URL.

Either way, if <script src=""> is able to load the file, then XHR should 
be able to load the file as well. If there were security preferences 
preventing the loading of files using XHR, they would also prevent the 
loading of that file using <script src=""> for data (since the exact same 
security issues would be relevant).


> (The issue is also relevant to applications that are not completely 
> local and offline but may use HTTP connections for various purposes. For 
> them, the point is that HTTP requests should not be done in vain, e.g. 
> for a large static data file.)

XHR would give you far more control over this than <script src="">.


> So the question is: if I can use images and scripts in separate files in 
> that setup, accessed directly as local files by the browser (or alike), 
> why canít I do the same for plain text, CSV, or XML data?

You can. Use XHR.


> If there is a security risk, then surely it must be bigger for <script> 
> that refers to a JavaScript file via src=... than for <script> that 
> refers to a plain text file via src=...

Actually no; running a script doesn't let you inspect the script's 
contents.


> Yet the latter is disallowed.

If it is disallowed, it would be disallowed for <script src=""> and XHR 
equally.


> Whatever the reasons might be, I donít think specifications should 
> declare it as prohibited, though they can warn that implementations may 
> pose such restrictions.

The specifications allow you to do this. XHR is the tool to do it.

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 8 August 2013 18:58:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC