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

Issue 404501 link

Starred by 6 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocked on:
issue 449224



Sign in to add a comment

[Resource Timing] secureConnectionStart is 0 but it should be a timestamp

Reported by stevesou...@gmail.com, Aug 17 2014

Issue description

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

Steps to reproduce the problem:
1. Go to any https site, eg, https://www.google.com/ .
2. Load the same website again.
3. Open console and enter performance.timing.secureConnectionStart.
==> Note that the value is "0".

What is the expected behavior?
According to the spec this should be a timestamp since the secureConnectionStart property *is* available and the scheme of the current page *is* HTTPS.

What went wrong?
It looks like the bug occurs when an existing TCP connection is being re-used (note that connectStart == connectEnd which implies a re-used connection). But in this situation secureConnectionStart should == connectStart. Because of this bug people tracking SSL metrics would expect that if the scheme *is* HTTPS and secureConnectionStart is not "undefined" then they should be able to get the SSL connect time from (connectEnd - secureConnectionStart) but in fact this will return an extremely large value. This erroneous metric will likely go undetected and invalidate aggregate SSL stats.

Here's the relevant paragraph from the spec ( http://www.w3.org/TR/navigation-timing-2/#dom-performancenavigationtiming-secureconnectstart ): "This attribute is optional. User agents that don't have this attribute available MUST set it as undefined. When this attribute is available, if the scheme of the current page is HTTPS, this attribute MUST return a DOMHighResTimeStamp with a time value equal to the time immediately before the user agent starts the handshake process to secure the current connection. If this attribute is available but HTTPS is not used, this attribute MUST return zero."

It's possible you could interpret secureConnectionStart as being not available - in which case its value should be undefined. But the spec is clear that the only time it should be zero is when HTTPS is not used, which is not the case here.

Did this work before? N/A 

Chrome version: 36.0.1985.143  Channel: stable
OS Version: OS X 10.9.4
Flash Version: Shockwave Flash 14.0 r0

Bug also occurs in Chrome Canary (28).
 
chrome-secureconnectionstart.png
32.3 KB View Download
The same issue occurs for Resource Timing. 
chrome-secureconnectionstart-resourcetiming.png
28.9 KB View Download
Labels: Needs-Feedback
 stevesoudersorg,,Thanks for your response.Are you still seeing the same issue with Latest Canary :39.0.2146.0 and also with Latest stable :37.0.2062.103?
Few such issues has been fixed with latest chrome version,if you still find the same we can go ahead for further triageing it.
Thanks in Advance.

still happens
Cc: tkonch...@chromium.org
Able to repro the issue on mac 10.9 chrome version 39.0.2169.3 and stable 37.0.2062.122 - 0 displayed in the console for performance.timing.secureConnectionStart

Please find the screenshots

The same is observed on win also. Could you please confirm the actual and expected behaviors in latest stable

Screen Shot 2014-09-25 at 11.46.43 PM.png
105 KB View Download
Screen Shot 2014-09-25 at 11.49.14 PM.png
64.8 KB View Download

Comment 5 by ajha@chromium.org, Sep 30 2014

Could you please review the C#4 and update the thread.

Comment 6 by ajha@chromium.org, Dec 23 2014

Labels: -OS-Mac -Needs-Feedback OS-All M-41 m-41
Status: Untriaged
Triaging this for further investigation.

This is reproducible across Linux and Windows-7 on latest M-41(41.0.2257.0) as well & has been behaving the same since older chrome version(27.0.1449.0 (Official Build 189738)).

Comment 7 by ajha@chromium.org, Dec 23 2014

Cc: ajha@chromium.org
Labels: -m-41

Comment 8 by pennymac@google.com, Jan 15 2015

Labels: -M-41 M-42 MovedFrom-41
Moving all non essential bugs to the next Milestone.
Cc: sidv@chromium.org cbentzel@chromium.org
FWIW, related:  crbug.com/449224  -- hopefully fixing that (which is a bigger issue) would address this as well.
Labels: -M-42 MovedFrom-42
[AUTO] This issue has already been moved once and is lower than Priority 1,therefore removing mstone.
[Automated message] This issue does not seem to be a V8 issue. The label Cr-Blink-JavaScript will be removed next week. The label Cr-Blink will be added instead. If you think that this issue is correctly labeled as a V8 issue please contact hablich@.
Labels: -Cr-Blink-JavaScript NotV8 Cr-Blink
[Automated message] This issue does not seem to be a V8 issue. The label Cr-Blink-JavaScript is removed. The label Cr-Blink is added instead. If you think that this issue was correctly labeled as a V8 issue please contact hablich@.
Labels: -Cr-Blink Cr-Blink-PerformanceAPIs
I still see this behavior in Stable (48.0.2564.116 (64-bit)) and Canary (51.0.2663.0 canary (64-bit)).
Status: Available (was: Untriaged)
Labels: Hotlist-PerformanceAPIs
Blockedon: 449224
Summary: [Resource Timing] secureConnectionStart is 0 but it should be a timestamp (was: secureConnectionStart is 0 but it should be a timestamp)
Components: Blink>PerformanceAPIs>ResourceTiming
Components: -Blink>PerformanceAPIs
Still blocked on  issue 449224 .
Actually, it looks like  issue 449224  has been addressed, so this isn't blocked.
Owner: npm@chromium.org
Status: Assigned (was: Available)
Note that performance.timing is now deprecated [1]. The bug still shows up in ResourceTiming and NavigationTiming. I have a tentative fix but the two specs say different things about the value of secureConnectionStart when the connection is not secure, so I'll file a bug about that.

[1] https://w3c.github.io/navigation-timing/#obsolete 
Hey Nicolas - CSM triage here. Where are we at on this bug?
Project Member

Comment 26 by bugdroid1@chromium.org, Dec 7 (3 days ago)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c92f6ff28e1c27cd004201f48fe9e2eb16bbc749

commit c92f6ff28e1c27cd004201f48fe9e2eb16bbc749
Author: Nicolas Pena <npm@chromium.org>
Date: Fri Dec 07 22:38:42 2018

Fix secureConnectionStart when connection is reused

Per ResourceTiming spec, if a connection is reused
then secureConnectionStart must return fetchStart, not 0.

Bug: 404501
Change-Id: Ica208c98cfea0afa9dd22e4edc83cc3c430c219f
Reviewed-on: https://chromium-review.googlesource.com/c/1363906
Commit-Queue: Nicolás Peña Moreno <npm@chromium.org>
Reviewed-by: Yoav Weiss <yoavweiss@chromium.org>
Cr-Commit-Position: refs/heads/master@{#614849}
[modify] https://crrev.com/c92f6ff28e1c27cd004201f48fe9e2eb16bbc749/third_party/blink/renderer/core/timing/performance_resource_timing.cc
[modify] https://crrev.com/c92f6ff28e1c27cd004201f48fe9e2eb16bbc749/third_party/blink/web_tests/external/wpt/resource-timing/resource_connection_reuse.html

Sign in to add a comment