1523291 - ResourceTiming secureConnectionStart is 0 for some HTTPS connections

Status: RESOLVED WORKSFORME

(Core :: Networking, defect, P3)

Description

[Nic Jansma]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce:

Load a HTTPS resource that is same-origin or has Timing-Allow-Origin HTTP Response Code set.

Fetch the resource from ResourceTiming.

Example test cases: https://nicj.net/dev/resourcetiming/error-resources.html

Actual results:

The secureConnectionStart attribute is 0 for ResourceTiming entries in many cases, when on HTTPS and same-origin or TAO is set.

I had originally thought this was just for 4xx or 5xx HTTP Response Code cases, but it also appears to occur with 200 responses as well.

e.g., this case where we see connectStart/connectEnd/domainLookupStart/domainLookupEnd (which are all TAO-restricted), yet secureConnectionStart is 0 on HTTPS resource:

{
"name": "https://sameorigin/404",
"entryType": "resource",
"startTime": 328,
"duration": 56,
"initiatorType": "img",
"nextHopProtocol": "h2",
"workerStart": 0,
"redirectStart": 0,
"redirectEnd": 0,
"fetchStart": 328,
"domainLookupStart": 328,
"domainLookupEnd": 328,
"connectStart": 328,
"connectEnd": 328,
"secureConnectionStart": 0,
"requestStart": 353,
"responseStart": 384,
"responseEnd": 384,
"transferSize": 2654,
"encodedBodySize": 2197,
"decodedBodySize": 5140,
"serverTiming": []
}

Expected results:

secureConnectionStart should be non-0 when on HTTPS and TAO check passes. For re-used connections, it should be equal to connectStart/connectEnd.

https://www.w3.org/TR/resource-timing-2/#dom-performanceresourcetiming-secureconnectionstart

Comment 1

[Nic Jansma]

Note the same test page shows non-0 secureConnectionStart for the NavigationTiming entry, and for an entry for a separate domain resource (https://fonts.googleapis.com/css?family=Open+Sans)

Comment 2

[Honza Bambas (:mayhemer)]

Valentin?

Comment 3

[BugBot [:suhaib / :marco]]

The priority flag is not set for this bug.
:selenamarie, could you have a look please?

Comment 4

[Nic Jansma]

I think this was fixed at some point. I currently see non-zero secureConnectionStart in all the places I'd expect.