Re: [ErrorLogging] Draft Specification

On Fri, Mar 29, 2013 at 5:55 AM, Reitbauer, Alois <Alois.Reitbauer@compuware.com<mailto: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.

[Alois] Yes, this should read "as". The point is that in operations I am more interested in real time information. Typically you will also send monitoring data to a different infrastructure than your own. So if the DNS problem is about my domain I would then get notified in real time. If your machine cannot resolve any DNS then I don't really care from an operational perspective. If there is a general network outage I will also be notified by third party tools like Compuwares Outage Analyzer [1]


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.

[Alois] My idea was only specifying the script file e.g.  JS-PRELOAD:  /monitor.js ; Domain: mydomain.com;


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).

[Alois] I am not really familiar with the spec, have to look into it.

[1] http://www.outageanalyzer.com/
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Compuware Austria GmbH (registration number FN 91482h) is a company registered in Vienna whose registered office is at 1120 Wien, Austria, Am Euro Platz 2 / Gebäude G.