Bug 225733 - Resource Timing: secureConnectionStart == 0 when a connection is re-used
Summary: Resource Timing: secureConnectionStart == 0 when a connection is re-used
Alias: None
Product: WebKit
Classification: Unclassified
Component: Platform (show other bugs)
Version: Safari 13
Hardware: Mac (Intel) macOS 10.15
: P2 Normal
Assignee: Alex Christensen
Depends on:
Reported: 2021-05-12 22:07 PDT by Nic Jansma
Modified: 2021-05-15 11:20 PDT (History)
3 users (show)

See Also:

Patch (5.09 KB, patch)
2021-05-13 09:14 PDT, Alex Christensen
ews-feeder: commit-queue-
Details | Formatted Diff | Diff
Patch (18.24 KB, patch)
2021-05-13 13:03 PDT, Alex Christensen
cdumez: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nic Jansma 2021-05-12 22:07:40 PDT
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:



  "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
Comment 1 Alex Christensen 2021-05-13 09:14:42 PDT
Created attachment 428519 [details]
Comment 2 Alex Christensen 2021-05-13 13:03:40 PDT
Created attachment 428550 [details]
Comment 3 Alex Christensen 2021-05-13 13:24:10 PDT
@Nic, the spec should probably be clarified to say that fetchStart should not be used if the persistent connection was not secure.
Comment 4 Nic Jansma 2021-05-13 18:38:08 PDT
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!
Comment 5 Alex Christensen 2021-05-14 09:07:40 PDT
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.
Comment 6 Chris Dumez 2021-05-14 09:49:20 PDT
Comment on attachment 428550 [details]

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


> 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)

Comment 7 Alex Christensen 2021-05-14 09:57:58 PDT
Comment 8 Nic Jansma 2021-05-15 11:20:37 PDT
@Alex ah yes that makes a lot of sense, thanks!