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'
Cc: Reitbauer, Alois (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