Copyright © 2012 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This specification defines an interface to store and retrieve error data related to the fetching of resources in the current document.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a work in progress and may change without any notices.
Please send comments to public-web-perf@w3.org (archived) with [ResourceErrorLogging] at the start of the subject line.
This document is produced by the Web Performance Working Group. The Web Performance Working Group is part of the Rich Web Clients Activity in the W3C Interaction Domain.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This section is non-normative.
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.
Today, site developers do not have real time web application availability data from their end users. Synthetic testing cannot truly provide global or near real-time availability data for real end users.
The example should be updated to be different than the NavigationErrorLogging example.
For example, a user visits http://example.com, which requests a number of image resources, causing the User Agent to send a HTTP request to the server. The server has a memory bug that causes a random set of responses to have a space in the middle of the HTTP response header, like so:
HTTP/1. 1 200 OK
Date: Thu, 24 Jan 2013 05:46:54 GMT
Content-Length: 2291
Content-Type: image/jpeg
In this example, the seventh character of the first response, incorrectly has a space (e.g., HTTP/1. 1 should be HTTP/1.1). When the server sends this response, this causes strict format validation issues at the CDN near the user to fail to process the request. So while the server sees a 200 OK HTTP response, the end user actually sees a 500 Server Error HTTP response.
The previous example described a case where the site developers may not actually know that end users are hitting this problem for quite some time. As the issue is random, it may not be caught by synthetic testing.
To address the need for complete and detailed information on the errors resulting from the navigation of the document and fetching of resources, the Resource Error Logging specification defines the ResourceErrorLogging interface. This 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.
The following script shows how a developer can use the ResourceErrorLogging interface to obtain accurate error timing data related to the previous and current navigations of the document.
<!doctype html>
<html>
<head>
</head>
<body onload="init()">
<script>
function init()
{
var errorList = window.performance.getEntriesByType("resourceError");
for (i = 0; i < errorList.length; i++)
{
if (window.console) console.log("Resource: " + errorList[i].name + "\n" +
"Error Category: " + errorList[i].errorCategory + "\n" +
"Error Type: " + errorList[i].errorType + "\n" +
"HTTP Code: " + errorList[i].httpResponseCode + "\n" +
"Time: " + new Date(errorList[i].startTime);
}
}
</script>
</body>
</html>
All diagrams, examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC 2119. For readability, these words do not appear in all uppercase letters in this specification.
Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.
Some conformance requirements are phrased as requirements on attributes, methods or objects. Such requirements are to be interpreted as requirements on user agents.
Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)
The IDL fragments in this specification must be interpreted as required for conforming IDL fragments, as described in the Web IDL specification. [Web IDL]
The construction "a Foo object", where Foo is actually an interface, is sometimes used instead of
the more accurate "an object implementing the interface Foo".
The term "navigation" refers to the act of navigating.
The term "JavaScript" is used to refer to ECMA-262, rather than the official term ECMAScript, since the term JavaScript is more widely known.
This section is non-normative.
This specification defines the ResourceErrorLogging interface to store and retrieve error data related to the fetching of resources in the current document.
ResourceErrorLogging interfaceinterface ResourceErrorLogging : PerformanceEntry {
readonly attribute ResourceErrorCategory errorCategory;
readonly attribute DOMString errorType;
readonly attribute unsigned short httpResponseCode;
};
enum ResourceErrorCategory { "redirect", "apppcache", "dns", "tcp", "request", "response" };
The ResourceErrorLogging interface participates in the
Performance Timeline and extends the
name, entryType,
startTime, and duration
attributes of the PerformanceEntry interface.
name attribute
The name attribute MUST return the
resolved URL of the requested resource. This attribute must not change
even if the fetch redirected to a different URL.
This attribute is extended from the PerformanceEntry interface.
entryType attribute
The entryType attribute MUST return the DOMString resourceError.
This attribute is extended from the PerformanceEntry interface.
errorCategory attribute
This attribute MUST return one of the following strings describing the category type of the error: redirect, appcache,
dns, tcp, request, and response.
errorType attributeThis attribute MUST return one of the following strings describing the specific type of the error or a vendor prefixed string:
Open Issue: We are working through the list of errors to consider standarizing in this specification.
httpResponseCode attribute
If this error is caused due to the fetching of a resource,
this attribute MUST return a short with the HTTP Response code number
that the User Agent recieved for the resource that caused this error. Otherwise, this attribute MUST be equal to 0.
Open Issue: Due to privacy and security concerns, we should limit the HTTP response codes to a subset of all codes.
startTime attribute
The startTime attribute MUST return a DOMHighResTimeStamp
with the time immediately after the User Agent logs the occurrence of the error, measured relative from the
navigationStart, the start of navigation of the document
where the error occurred.
This attribute is extended from the PerformanceEntry interface.
duration attribute
The duration attribute MUST return a DOMHighResTimeStamp
equal to 0.0. This attribute is extended from the PerformanceEntry interface.
The Performance Timeline specification should define a clearData(DOMString entry) method, where entry is a type of PerformanceEntry object buffer that is to be cleared. This method would currently apply to PerformanceResourceTiming, ErrorLogging, and ResourceErrorLogging buffers.
The Performance Timeline specification should define a setBufferSize(DOMString entry, unsigned long maxSize) method, where entry is a type of PerformanceEntry object buffer that is to be set. This method would currently apply to PerformanceResourceTiming, ErrorLogging, and ResourceErrorLogging buffers.
partial interface Performance {
attribute Function onresourceerrordatabufferfull;
};
onresourceerrordatabufferfull attributeThe callback onresourceerrordatabufferfull is triggered when the buffer used to store the list of ResourceErrorLogging objects is full.
The callback can be used to package existing ResourceErrorLogging objects and clear the buffered ResourceErrorLogging objects list.
While executing the onresourceerrordatabufferfull callback, ResourceErrorLogging objects will continue to be collected beyond the maximum limit of the resources allowed in the
ResourceErrorLogging objects interface until one of the following occurs:
clearData method is called: the PerformanceEntryList
will begin with the n+1th item if it exists and the first n elements are released, where n is the maximum number of resources allowed in the ResourceErrorLogging
interface. If the n+1th item does not exist, the buffer is cleared. The max length of the PerformanceEntryList
does not change unless otherwise specified by setBufferSize.
setBufferSize is called: the PerformanceEntryList
will extend and / or truncate to the buffer size specified.clearData or
setBufferSize is called during the execution of the onresourceerrordatabufferfull callback:
no updates are made to the PerformanceEntryList.
If the onresourceerrordatabufferfull callback is not defined and the buffer used to store the
ResourceErrorLogging objects is full,
the first ResourceErrorLogging object in the buffer will be discarded and the new
ResourceErrorLogging object will be appended to the end of the buffer, like a FIFO queue.
Vendor-specific proprietary user agent extensions are discouraged. If such extensions are needed, e.g., for experimental purposes, vendors MUST use the following extension mechanisms:
The value of the timing attributes must monotonically increase to ensure timing attributes are not skewed by adjustments to the system clock while recording error data. The difference between any two chronologically recorded timing attributes must never be negative. For all resources, including subdocument resources, the user agent must record the system clock at the beginning of the root document navigation and define subsequent timing attributes in terms of a monotonic clock measuring time elapsed from the beginning of the navigation.
setBufferSize method.
error.
null.
0.0.
onresourceerrordatabufferfull is defined,
the following steps must be followed.onresourceerrordatabufferfull callback.
onresourceerrordatabufferfull
callback, add them to the temporary buffer.
clearData method is called in the onresourceerrordatabufferfull callback,
clear all ResourceErrorLogging objects in the primary buffer.
Copy all ResourceErrorLogging objects in the temporary buffer to the
primary buffer.
setBufferSize method is called in the onresourceerrordatabufferfull callback,
set the maximum size of the primary buffer to the maxSize parameter. If the maxSize parameter is larger than the previous size of the primary buffer,
append ResourceErrorLogging objects in the temporary buffer to the primary buffer up to the maxSize parameter.
onresourceerrordatabufferfull is not defined,
remove the first ResourceErrorLogging object in the primary buffer and append this new
ResourceErrorLogging object to the end of the primary buffer.
This section is non-normative.
The ResourceErrorLogging interface exposes timing and other information for an error that has occurred in the current and previous navigations to the web page. Access to the ResourceErrorLogging interface is limited to the same origin.
I would like to offer my sincere thanks to Aaron Heady, Dan Austin, James Simonsen, Arvind Jain, Philippe Le Hegaret, and Jason Weber for their contributions to this work.