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

Back to XHR errors (was Re: Installing web apps)

From: Robin Berjon <robin@berjon.com>
Date: Tue, 7 Feb 2012 14:39:56 +0100
Cc: Marcos Caceres <w3c@marcosc.com>, Ian Hickson <ian@hixie.ch>, WebApps WG <public-webapps@w3.org>, Thomas Roessler <tlr@w3.org>, "Michael(tm) Smith" <mike@w3.org>
Message-Id: <A038A623-D8B6-4F49-858D-464792026FF6@berjon.com>
To: Tim Berners-Lee <timbl@w3.org>

Hi Tim,

On Feb 1, 2012, at 22:04 , Tim Berners-Lee wrote:
> I want to argue for XMLHTTPRequest 
> being designed to be able to be used not only in an untrusted web page,
> but e.g. from an installed widget, or node.js for that matter,
> which means returning a defined error response when the privilege is
> insufficient, instead of faking a network error.
> I've been trying to write code which will work in any of these.

In a Node context this should not be necessary. There's already support for HTTP requests there and it isn't based on XHR (in fact there seems to be a small cottage industry of people providing more usable wrappers around the very raw support that ships with the core). And that's fine because we don't really need interoperability there.

Having XHR report better errors when running in a Web technology context that happens to have elevated privileges could indeed be useful. That said, it should be easy to get consensus on that if we can get consensus on how such an elevated privileges system would work (or exist) in the first place. That's the blocker here, and would be the first thing to attend to.

In regular browser context, I tend to agree with Ian that exposing more information for a security-related error tends to be bad practice since it leaks information that could be leveraged by an attacker. That said, if you have a use case in which this feature is needed (in the regular browser security context) then it would help to see your code and understand more of what you're doing.

Robin Berjon - http://berjon.com/ - @robinberjon
Received on Tuesday, 7 February 2012 13:43:24 UTC

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