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]",
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:
Created attachment 428519 [details]
Created attachment 428550 [details]
@Nic, the spec should probably be clarified to say that fetchStart should not be used if the persistent connection was not secure.
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!
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 on attachment 428550 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=428550&action=review
> +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.
> +Box<WebCore::NetworkLoadMetrics> copyTimingData(NSURLSessionTaskTransactionMetrics *incompleteMetrics)
@Alex ah yes that makes a lot of sense, thanks!