W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: File API for Review

From: Arun Ranganathan <aranganathan@mozilla.com>
Date: Mon, 25 Mar 2013 10:45:39 -0700 (PDT)
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Web Applications Working Group WG <public-webapps@w3.org>
Message-ID: <92702361.3847442.1364233539607.JavaMail.root@mozilla.com>
----- Anne vK said:  -----
> On Tue, Mar 19, 2013 at 5:57 PM, Arun Ranganathan <arun@mozilla.com>
> wrote:
> > On Feb 13, 2013, at 11:37 AM, Anne van Kesteren wrote:
> > We're not actually leaving what exactly to return open to
> > implementors.  They *must* return a 500.  They *may* additionally
> > provide a message, which is akin to console messages.
> No, an HTTP status message is an actual thing and exposed via
> XMLHttpRequest.

You're right; this should be defined better in the File API.

> >>  Also, networkerror isn't really strongly defined; XMLHttpRequest
> >>  uses this to throw on network errors (NetworkError), and there
> >>  isn't currently a Fetch in HTML that leverages networkerrors.
> >>   This is not obviously reusable here in the blob: URL context.
> I think it is. Network error is for whenever something goes wrong
> with
> the request. Otherwise this would give a load event rather than an
> error event. data: URLs use network errors too now:
> http://xhr.spec.whatwg.org/#data:-urls-and-http

So just to be clear, do you think we should remove "500-style" responses altogether, and *completely defer* to network error, which essentially involves throwing on expired / revoked / invalid Blob URLs?  I'm ok with that if so.

-- A*
Received on Monday, 25 March 2013 17:46:07 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:52 UTC