- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 12 Aug 2009 12:06:38 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Olli Pettay <Olli.Pettay@helsinki.fi>, arun@mozilla.com, Web Applications Working Group WG <public-webapps@w3.org>
On Wed, Aug 12, 2009 at 12:01 PM, Anne van Kesteren<annevk@opera.com> wrote:
> On Wed, 12 Aug 2009 20:09:20 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Wednesday, August 12, 2009, Anne van Kesteren <annevk@opera.com>
>> wrote:
>>> On Tue, 11 Aug 2009 22:57:51 +0200, Jonas Sicking <jonas@sicking.cc>
>>> wrote:
>>>> xhr.open("GET", myFile.slice(x, y).fileDataURI);
>>>> xhr.send();
>>>
>>> FWIW I'm opposed to abusing XMLHttpRequest in this way and I actually
>>> think that when using the filedata URL scheme some kind of exception
>>> needs to be thrown. Similarly to when you would use mailto or something.
>>
>> Why?
>
> 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.
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.
/ Jonas
Received on Wednesday, 12 August 2009 19:07:39 UTC