- From: Arun Ranganathan <arun@mozilla.com>
- Date: Tue, 19 Mar 2013 13:57:54 -0400
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Web Applications Working Group WG <public-webapps@w3.org>
On Feb 13, 2013, at 11:37 AM, Anne van Kesteren wrote: > >> Specification bugs still exist > > I think we should rename URI to URL. That's what everyone is converging on. > Done. > I'm also not convinced that leaving what exactly to return in the HTTP > scenario open to implementors is a good thing. (There isn't an HTTP scenario here). > So what I actually think we should do here is treat this as a networkerror. XMLHttpRequest already knows about that concept and every other end point also deals with network errors in a predictable and standardized way. Phrasing such as "Act as if a network error occurred" seems sufficient for now (until Fetch provides hooks). 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. 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. The spec. doesn't need to mention anything about throwing -- we're returning a 500 if a blob: URL cannot be dereferenced, not throwing an exception. This is specific, and not left to implementations to determine. > Just like HTML, CSS, etc. this specification should defer to > http://encoding.spec.whatwg.org/ for its encoding related > requirements. Done (and uses most of your proposed changes): http://dev.w3.org/2006/webapi/FileAPI/#encoding-determination > > I don't think we should throw for limitations on URL length. We always > leave undefined lengths unaddressed in specifications, including with > regards to how to handle them. > Done. -- A*
Received on Tuesday, 19 March 2013 17:58:35 UTC