RE: [ErrorLogging] Draft Specification

I put some additional thoughts on the use cases. The main use case is that we get information on web resources which fail to load properly. The main causes are TCP, DNS issues as well as 4x/5x server responses. The latter ones can also be caused by proxies, firewalls etc. In this case they are not detectable on the server side. These are typical cases where synthetic monitoring is used, most of them could be supported by the Error Spec except the most important one if the main document fails to load.

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.

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

The error spec is an important piece of the puzzle. Solving the full use case, however, will require a bit more work. The  header JavaScript loading or something similar is another important piece.

Thoughts?

// Alois

From: Jatinder Mann <jmann@microsoft.com<mailto:jmann@microsoft.com>>
Date: Wednesday, March 27, 2013 6:52 PM
To: "Austin,Daniel" <daaustin@paypal-inc.com<mailto:daaustin@paypal-inc.com>>, "public-web-perf@w3.org<mailto:public-web-perf@w3.org>" <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Subject: [Dynatrace.com]RE: [ErrorLogging] Draft Specification
Resent-From: "public-web-perf@w3.org<mailto:public-web-perf@w3.org>" <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Resent-Date: Wednesday, March 27, 2013 6:55 PM

Thanks for the offer Daniel. We decided to spend next week’s call on Diagnostics and Error Logging. A list of errors will help in that discussion.

Thanks,
Jatinder

From: Austin,Daniel [mailto:daaustin@paypal-inc.com]
Sent: Wednesday, March 27, 2013 10:31 AM
To: 'public-web-perf@w3.org<mailto:'public-web-perf@w3.org>'
Subject: RE: [ErrorLogging] Draft Specification

Hi Team,

                I’m on the call, arrived late and now have to leave early. My regrets. On reading this draft from Jatinder, I noticed the part on error and status codes. I’m willing to volunteer to put together a list that we use here internally for this and submit it to the group by next week’s meeting. Just to spark some discussion. Talk soon!

Regards,

D-

From: Jatinder Mann [mailto:jmann@microsoft.com]
Sent: Wednesday, March 27, 2013 9:27 AM
To: 'public-web-perf@w3.org<mailto:'public-web-perf@w3.org>'
Cc: Reitbauer, Alois (Alois.Reitbauer@compuware.com<mailto:Alois.Reitbauer@compuware.com>); Aaron Heady (BING)
Subject: [ErrorLogging] Draft Specification

Accurately measuring performance characteristics of web applications is an important aspect in helping site developers understand how to make their web applications faster. Likewise, measuring and understanding when web applications are not properly loading for end users due to network errors is an example of the worst case web browsing performance. One of the areas we wanted to focus in this chartered period is Diagnostics and Error Logging. Within that focus area, with help from Aaron Heady and Alois, I have put together a first draft of the Error Logging spec: https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ErrorLogging/Overview.html.


Today, site developers do not have real time web application availability data from their end users. While synthetic testing gives you some data, it can’t truly provide global or near real-time availability data for real end users. For example, if a web server has a memory bug that causes a random set of HTTP responses to have a space in the middle of the HTTP response header, when the server sends this response, this may cause strict format validation issues at the CDN near the user to fail to process the request. So while the server may see a 200 OK HTTP response, the end user may actually see a 500 Server Error HTTP response. The site owner may not know for a long time that the user cannot see their web page and will not be able to correct this issue in a timely fashion.

The ErrorLogging interface allows JavaScript mechanisms to provide complete client-side error data on the navigation of the document and fetching of resources within the applications. As it is typically impossible to obtain error data through JavaScript mechanisms during an aborted navigation due to the error, this data is persisted across sessions. This interface is defined to use the Performance Timeline API, so its modelled very closely to the Resource Timing API.

As of right now, I haven’t filled out the errorTypes attribute. I’m not yet sure if we want to go with very specific or generic error types. The former would mean we define each possible problem with TCP, DNS and HTTP. The latter would be to just provide some examples of common issues to be used as a template for each scenario. Being very specific would allow more consistent parsing across browsers, but it would also mean that any case we didn’t cover would end up as a vendor prefixed entry. I think we should discuss this further.

Please provide feedback to this specification. Let’s also spend some time on the working group call going through this spec and other Diagnostics and Error Logging areas.

Thanks,
Jatinder
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.