Resource Timing: secureConnectionStart == 0 when a connection is re-used

• Component: Platform
• Status: RESOLVED FIXED

[Nic Jansma]

When a TLS connection is re-used, the secureConnectionStart attribute returns 0.

It should be set to the same as fetchStart, if a persistent connection is re-used, per:

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

Example:

{
  "name": "[some re-used TLS connection URL]",
  "entryType": "resource",
  "startTime": 121,
  "duration": 0,
  "initiatorType": "link",
  "nextHopProtocol": "",
  "workerStart": 0,
  "redirectStart": 0,
  "redirectEnd": 0,
  "fetchStart": 121,
  "domainLookupStart": 121,
  "domainLookupEnd": 121,
  "connectStart": 121,
  "connectEnd": 121,
  "secureConnectionStart": 0,
  "requestStart": 121,
  "responseStart": 121,
  "responseEnd": 121
}

In the above example, secureConnectionStart should probably be 121 (the same as fetchStart, which is also what domainLookup* and connect* use).

This can also be seen in WPT test failures:

* https://wpt.fyi/results/resource-timing/resource_connection_reuse_mixed_content.html?label=experimental&label=master&aligned
* https://wpt.fyi/results/resource-timing?label=experimental&label=master&aligned

[Alex Christensen]

Created attachment 428519 [details]
Patch

[Alex Christensen]

Created attachment 428550 [details]
Patch

[Alex Christensen]

@Nic, the spec should probably be clarified to say that fetchStart should not be used if the persistent connection was not secure.

[Nic Jansma]

Wow, that was an amazingly fast fix.  Thanks Alex!

I'm not totally following on the spec clarification, mind if I bring this up at a future W3C WebPerf call?

Great work, appreciated!

[Alex Christensen]

I'm happy to discuss, but it's as simple as this:  I had to only set secureConnectionStart to fetchStart if the protocol was HTTPS.  If I did it for all protocols, tests like resource-timing/resource_connection_reuse.html start failing because they check that secureConnectionStart is 0 and it is often reusing an unencrypted TCP connection.  Tests like resource-timing/resource_connection_reuse.https.html should start passing because of this change.

[Chris Dumez]

Comment on attachment 428550 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=428550&action=review

r=me

> Source/WebCore/platform/network/cocoa/NetworkLoadMetrics.mm:33
> +static Box<WebCore::NetworkLoadMetrics> packageTimingData(double fetchStart, double domainLookupStart, double domainLookupEnd, double connectStart, double secureConnectionStart, double connectEnd, double requestStart, double responseStart, bool reusedTLSConnection, NSString *protocol)

WebCore:: should not be necessary.

> Source/WebCore/platform/network/cocoa/NetworkLoadMetrics.mm:54
> +Box<WebCore::NetworkLoadMetrics> copyTimingData(NSURLSessionTaskTransactionMetrics *incompleteMetrics)

ditto.

[Alex Christensen]

r277493

[Nic Jansma]

@Alex ah yes that makes a lot of sense, thanks!

[Alex Christensen]

*** Bug 205768 has been marked as a duplicate of this bug. ***