Re: [ErrorLogging] Draft Specification

All,

We at Netflix would find detailed network error reporting very useful. I
will certainly look into the proposal in more detail.

I have one question, though. I've heard before that the reason more
detailed error reporting is not available on XHR, media elements etc. is
due to privacy concerns: that detailed error information could be used for
fingerprinting, or mapping a user's local network. Is this a concern ? What
is the approach to that aspect in this work ?

...Mark

On Fri, Mar 29, 2013 at 5:55 AM, Reitbauer, Alois <
Alois.Reitbauer@compuware.com> wrote:

>  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>
> Date: Wednesday, March 27, 2013 6:52 PM
> To: "Austin,Daniel" <daaustin@paypal-inc.com>, "public-web-perf@w3.org" <
> public-web-perf@w3.org>
> Subject: [Dynatrace.com]RE: [ErrorLogging] Draft Specification
> Resent-From: "public-web-perf@w3.org" <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<daaustin@paypal-inc.com>]
>
> *Sent:* Wednesday, March 27, 2013 10:31 AM
> *To:* '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 <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
>   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.
>