On Thu, Aug 13, 2009 at 3:38 AM, Anne van Kesteren<ann...@opera.com> wrote: > On Wed, 12 Aug 2009 21:06:38 +0200, Jonas Sicking <jo...@sicking.cc> wrote: >> On Wed, Aug 12, 2009 at 12:01 PM, Anne van Kesteren<ann...@opera.com> >> wrote: >>> Because we'd need to define how this works and define that non-GET, >>> non-null send(), setRequestHeader(), etc. are all not having any effect >>> for filedata URLs. That seems silly. It seems way better to admit that >>> XMLHttpRequest provides an HTTP API and not a File API, in my opinion. >> >> In order for filedata URLs to be viable in the File API spec in any >> form, it needs to be defined to the level of detail that it is useful >> for any consumer of URLs. Thus it has to define answers to your >> questions above. No changes needed to the XMLHttpRequest spec, or >> XMLHttpRequest implementations. > > XMLHttpRequest is not a consumer of any kind of URL. It is designed > specifically around "http" and "https". That in certain contexts user agents > also allow "file" does not make it any more generic in my opinion. Compare > this with <img> which handles "data" and "javascript" fine too, for instance. > > The API XMLHttpRequest exposes also does not have much to do with URLs or > file resources, it has to do with HTTP. It makes sense for the filedata URL > specification to state that if the file is no longer available that it is > equivalent to 404, but that does not extend to defining how it interacts with > a full HTTP API.
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? >> So if we don't want XMLHttpRequest to work with filedata URLs, we >> would need to define an explicit exception in the XMLHttpRequest >> specification. And implementations would need to add explicit code >> that rejects filedata URLs. *That* seems silly IMHO. > > 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. 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:..."; > / Jonas
