W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2014

Re: [SRI] Towards v1 - do we need error reporting?

From: Brian Smith <brian@briansmith.org>
Date: Wed, 10 Dec 2014 16:20:09 -0800
Message-ID: <CAFewVt6vW-iGe7eDDbNJQnkbPOfL6N1wwZbK7pO0JNH_zTfS5g@mail.gmail.com>
To: Brad Hill <hillbrad@gmail.com>
Cc: Devdatta Akhawe <dev.akhawe@gmail.com>, Ben Toews <btoews@github.com>, Frederik Braun <fbraun@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Dec 10, 2014 at 12:57 PM, Brad Hill <hillbrad@gmail.com> wrote:
> +1 on error reporting.  Especially as this is an experiment, I think it will
> be important to allow individual content providers to gather and report on
> their experiences with the spec, not just rely on browser vendor telemetry.

I think it is useful to be notified of errors. But, it isn't clear to
me why a SRI-specific error reporting mechanism is a good idea. I
would be just as interested in knowing if my CDN was returning 404s,
or if DNS failed to resolve for a CDN host, or other things. If at all
reasonable, I think it would be better to create an error
handling/reporting mechanism that is more general, so that every spec
doesn't need to create its own reporting mechanism from scratch or by
(effectively) copy/pasting the CSP one.

In particular, perhaps all we need is a way of doing something like this:

    <link rel=network-failure-handler
href="//not-the-cdn.example.com/handle-network-errors.js">

Which would indicate a script that is loaded and executed when a
network failure occurs, where the script can register an event handler
that will process events for every failed load (including, in
particular, the load that causes it to be loaded).

Cheers,
Brian
Received on Thursday, 11 December 2014 00:20:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:08 UTC