W3C home > Mailing lists > Public > public-web-perf@w3.org > April 2013

Re: [ErrorLogging] Draft Specification

From: Ilya Grigorik <igrigorik@google.com>
Date: Sun, 31 Mar 2013 17:31:33 -0700
Message-ID: <CADXXVKpQ6A89A0_C4gHqgMmXJ_c06woGoSd1oCSPHJ50E13sDA@mail.gmail.com>
To: "Reitbauer, Alois" <Alois.Reitbauer@compuware.com>
Cc: Jatinder Mann <jmann@microsoft.com>, "Austin,Daniel" <daaustin@paypal-inc.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
On Fri, Mar 29, 2013 at 5:55 AM, Reitbauer, Alois <
Alois.Reitbauer@compuware.com> wrote:

> In the current example this is exactly what happens. I don't see the value
> in saving this information and sending it later when the connection is up
> again. For an operational issue like this live data is crucial. Having this
> information after the fact is not valuable.

Perhaps that should read.. not *as* valuable? If my DNS server can't
resolve your hostname, then there is no magic trick for somehow instantly
reporting that to your server. I think, by definition, an error reporting
mechanism would have to buffer certain class of errors, and report them
later. Incidentally, defining how much to buffer, and when to beacon this
data is a whole separate discussion.

> This reminded my of a RUM discussion we had internally a while ago. The
> main point was to allow loading JavaScript via HTTP headers and also define
> expiration. Think of it as a cookie, but with a JavaScript file. The script
> will then be executed after it is loaded. If it is set on a domain, it will
> always be executed.
>  Combining this approach with error logging would allow to immediately
> alert in cases where the actual document cannot be loaded. The script 
> with monitoring code  will be cached and executed although the page cannot
> be loaded. The script extracts the error information and beacons it to a
> monitoring infrastructure (obviously not your servers, which are down).

I'm not sure I follow. Are you literally saying "Header: <javascript
here>"? Because if so, that seems like a very expensive way to do this.

I think we should take a close look at CSP policy and error reporting
mechanisms.. They've already shipped this, and there is a lot to be said
for re-use of same mechanisms and concepts:
- http://www.w3.org/TR/CSP/#content-security-policy-report-only-header-field
- http://www.w3.org/TR/CSP/#sample-violation-report

I'd prefer an automated solution, like CSP approach above, instead of a
manual implementation (as described in the spec currently).

Received on Monday, 1 April 2013 00:32:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:35 UTC