New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 9 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment
link

Issue 460879: [Resource Timing] Missing PerformanceResourceTiming entries for Requests that don't receive a Response

Reported by dajdav...@gmail.com, Feb 23 2015

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36

Example URL:
http://www.co-operativeinsurance.co.uk/petinsurance/cat-insurance

Steps to reproduce the problem:
1. Load above URL with Devtools network panel open
2. Note http://10.64.30.186/assets/images/insurance/common/av_tick.png fails to load (TCP connection fails as href is wrong)
3. Inspect the PerformanceTimeLine entries - window.performance.getEntriesByType('resource')

What is the expected behavior?
W3C ResourceTiming spec is unclear on what the behaviour should be but my expectation would be an entry should be created for the URL in error.

FF Nightly 38.0a1 (2015-02-04) and IE 11.0.9600.17501 both create an entry in this case

What went wrong?
There is no PerformanceTimelineEntry for http://10.64.30.186/assets/images/insurance/common/av_tick.png 

Did this work before? N/A 

Chrome version: 40.0.2214.111  Channel: stable
OS Version: OS X 10.9.5
Flash Version: Shockwave Flash 16.0 r0

Raised spec issue on W3C Perf Group mailing list
 

Comment 1 by y...@yoav.ws, Feb 23 2015

Cc: y...@yoav.ws

Comment 2 by igrigo...@chromium.org, Feb 23 2015

Cc: igrigo...@chromium.org

Comment 3 by rsleevi@chromium.org, Feb 25 2015

Labels: -OS-Mac OS-All OWP-Standards-Compatibility Cr-Blink-Performance-APIs
Sounds like a spec bug if the spec is unclear ;) Ilya, could you raise this up the pole if so?

Comment 4 by rsleevi@chromium.org, Feb 25 2015

Labels: -Cr-Internals-Network
Tentatively removing network label, as this appears to be a spec issue first, and an implementation (Blink) issue second.

Comment 5 by igrigo...@chromium.org, Feb 25 2015

Planning to discuss it tomorrow on the perf-wg call.

Opened an issue: https://github.com/w3c/resource-timing/issues/12

Comment 6 by rponnada@chromium.org, Feb 27 2015

Labels: TE-NeedsFurtherTriage

Comment 7 by laforge@google.com, Aug 4 2015

Labels: -Cr-Blink-Performance-APIs Cr-Blink-PermissionsAPI
Manually move Cr-Blink-Performance-APIs to Cr-Blink-PermissionsAPI

Comment 8 by tkent@chromium.org, Aug 5 2015

Labels: -Cr-Blink-PermissionsAPI Cr-Blink-PerformanceAPIs

Comment 9 Deleted

Comment 10 Deleted

Comment 11 by igrigo...@chromium.org, May 2 2016

Labels: -TE-NeedsFurtherTriage Te-NeedsFurtherTriage
I'll attempt to summarize the discussions to date, for additional background see [1], [2]. 

The Resource Timing L1 spec did not specify whether unsuccessful (4xx, 5xx, DNS/TCP timeouts, etc) requests should be surfaced in the Performance Timeline. As a result, different browsers have different behaviors: IE surfaces ResourceTiming entries but some of the timing fields are set to 0; Firefox surfaces ResourceTiming entries but sets most fields to 0; Chrome does *not* surface any ResourceTiming entries. We'd like to resolve this and converge on same behavior in RT L2. With that in mind...

(1) Developers can already measure the duration (time from dispatch to success or error callback) of a fetch, regardless of the response status or origin. Effectively, this is also the minimum ResourceTiming object: {name (url), startTime, duration}.
(2) ResourceTiming exposes additional timestamps (e.g. start time of DNS lookup, TCP handshake, etc.) if the resource is a same-origin resource, or if the third-party origin allows it to surface these timestamps by providing the Timing-Allow-Origin (TAO [3]) opt-in header.

Based on the above, I'd like to propose the following behavior for RT L2: 

(a) We omit requests that are blocked by CSP or Mixed Content - i.e. if a fetch is blocked by CSP, there is no ResourceTiming entry.
(b) Otherwise, we surface all requests regardless of their response codes (2xx/4xx/5xx, etc) - see [1].
 - (c) All ResourceTiming entries are subject to "timing allow check" algorithm - see [3].
 - (d) Entries that pass the TAO algorithm in (c) should show all timestamps up to the failure.
 -- (e) Cross-origin requests that fail due to a connection error (e.g. DNS or TCP timeout) are treated as lacking TAO opt-in and should only show the {name, startTime, duration} fields.

A couple of concrete examples.. Let's say the page's origin is foo.com and we fetch:

(i) foo.com/broken-thing -> 4xx/5xx: Request is same-origin and passes TAO check. We will surface ResourceTiming object with all available fields.
(ii) bar.com/broken-thing -> 4xx/5xx: Request is cross-origin. If the response provides the TAO opt-in header, then we will surface ResourceTiming object with all the same fields as (i). Otherwise, we will surface a ResourceTiming object with only {name, startTime, duration}. 
(iii) foo.com/connection-error -> timeout: request is same-origin and passes TAO check. We will surface ResourceTiming object with all the available timestamps, up to the point of failure.
(iv) bar.com/connection-error -> timeout: request is cross-origin and we don't know the TAO policy. Hence, we assume TAO opt-in is missing and will surface a ResourceTiming object with only {name, startTime, duration}. 


## Privacy and security... 

For requests that don't pass the TAO check (cross-origin without TAO opt-in, or cross-origin connection failures), I don't believe the above behavior exposes anything new, as developers can already measure the duration of any fetch. 

For requests that pass the TAO check (same-origin, or cross-origin with TAO opt-in), we do provide a more detailed breakdown of the failure. However, for cross-origin the origin has to opt-in, and for same-origin the developers can already obtain TCP/DNS/other timestamps for this origin via NavigationTiming entry of the parent page, so the additional exposure is minimal.


## The why...

Surfacing failed requests is an important use case for helping site developers to detect and resolve performance issues with their application: "Every time we talk to site owners about resource timing, and once they understand it, they want to know if it will tell them which resources aren't responding, because very few people care about timing the resources that work correctly. - Philip Tellis (Soasta)" [4]. 

Today, this is unnecessarily hard, unreliable, and requires that they wrap XHR's and other API's in their own handlers, etc. The proposed RT L2 behavior would address this by exposing such entries in the Performance Timeline.


## Related discussions:
[1] https://github.com/w3c/resource-timing/issues/12 
[2] https://lists.w3.org/Archives/Public/public-web-perf/2015Feb/0065.html
[3] http://w3c.github.io/resource-timing/#timing-allow-origin
[4] https://github.com/w3c/resource-timing/issues/12#issuecomment-98141056

Comment 12 by kolos@chromium.org, May 9 2016

Cc: kolos@chromium.org

Comment 13 by dvadym@chromium.org, May 25 2016

Proposed changes look like quite small improvements of the current API they change behavior only for unsuccessful requests to same origin or third party with explicit opt-in with TAO header. So they shouldn't increase possibility for user fingerprinting. 

The Privacy team doesn't have any concerns about them.

Comment 14 by panicker@chromium.org, Jul 14 2016

Owner: igrigo...@chromium.org
Ilya, can you update this bug when the spec is ready. Then feel free to assign to me for implementation.

Comment 15 by igrigo...@chromium.org, Jul 15 2016

Cc: panicker@chromium.org
Labels: -Te-NeedsFurtherTriage Hotlist-PerformanceAPIs
Status: ExternalDependency (was: Unconfirmed)
Will do. Adding you to the cc list for now.

Comment 16 by igrigo...@chromium.org, Jul 22 2016

Labels: -Pri-2 Pri-3

Comment 17 by ksakamoto@chromium.org, Mar 15 2017

Issue 700654 has been merged into this issue.

Comment 18 by tdres...@chromium.org, Aug 14 2017

Summary: [Resource Timing] Missing PerformanceResourceTiming entries for Requests that don't receive a Response (was: Resource Timing - Missing PerformanceResourceTiming entries for Requests that don't receive a Response)
Any update on the spec status here?

Comment 19 by igrigo...@google.com, Aug 18 2017

Status: WontFix (was: ExternalDependency)
Complicated. We agreed in [1] that error cases _should_ be available via RT, and even landed some spec updates for it, but for unrelated reasons those were backed out later in favor of spelling out this behavior in RT L3 -- which is still on the drawing board. 

As such, I'm closing this as a wontfix; we need to land spec language and tests first, and we'll file new implementation bugs against all UA's once those land.

[1] https://github.com/w3c/resource-timing/issues/12#issuecomment-248445564

Comment 20 by nicjan...@gmail.com, Jan 28

Can I request that this be re-evaluated for a possible fix in Chrome?  IE, Edge and FF all surface failure entries today.

For RT L2, we clarified that network and HTTP failures MAY be included -- we just didn't specify any additional fields that would clarify _how_ it failed:

https://www.w3.org/TR/resource-timing-2/#resources-included-in-the-performanceresourcetiming-interface

> If a resource fetch was aborted due to a networking error (e.g. DNS, TCP, or TLS error), then the fetch MAY be included as a PerformanceResourceTiming object in the Performance Timeline with initialized attribute values up to the point of failure - e.g. a TCP handshake error should report DNS timestamps for the request, and so on.

Comment 21 by npm@chromium.org, Jan 28

Owner: ----
Status: Available (was: WontFix)
I agree that this should be changed in Chrome. I think there's no need to wait for the spec since other browsers already expose these, which means that if something was spec'd as a 'MUST' then it would probably be exposing the failures. Given that there are legitimate use cases for exposing failures, we should look into fixing this.

Comment 22 by yoavweiss@chromium.org, Feb 9

Cc: yoavweiss@chromium.org

Sign in to add a comment