Re: [File API] events vs callbacks

On Thu, Aug 13, 2009 at 3:38 AM, Anne van Kesteren<annevk@opera.com> wrote:
> On Wed, 12 Aug 2009 21:06:38 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Wed, Aug 12, 2009 at 12:01 PM, Anne van Kesteren<annevk@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

Received on Thursday, 13 August 2009 17:25:32 UTC