- From: Jukka K. Korpela <jkorpela@cs.tut.fi>
- Date: Thu, 08 Aug 2013 17:01:25 +0300
- To: whatwg <whatwg@lists.whatwg.org>
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. > 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. (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.) 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? 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=... Yet the latter is disallowed. 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. Yucca
Received on Thursday, 8 August 2013 14:01:58 UTC