New issue
Advanced search Search tips

Issue 836063 link

Starred by 3 users
Status: WontFix
Owner: ----
Closed: May 2018
Cc:
phanindra.mandapaka@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

SSL timing missing from some requests

Reported by joewynn...@gmail.com, Apr 24 2018 
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.10 Safari/537.36

Steps to reproduce the problem:
1. Open the Developer Tools
2. Navigate to https://qa-ext11-www.edmunds.com/?carousel-autoplay=off
3. Go to the Network panel of the Developer Tools
4. Click on the initial document request
5. Click on the Timing tab
6. Observe that the SSL section is missing, even though TLS negotiation took place for this request.
7. Bonus: Find the resource in performance.getEntries() and observe that the secureConnectionStart value is 0 when it should be >0.

What is the expected behavior?
Requests that performed TLS negotiation should have timing information for that negotiation. Their corresponding PerformanceResourceTiming entries should also have a secureConnectionStart value of >0.

What went wrong?
The timing for the TLS negotiation seems to be missing.

Did this work before? Yes 

Chrome version: 67.0.3396.10  Channel: dev
OS Version: 
Flash Version:
edmunds-missing-ssl.png
106 KB View Download

Comment 1 by joewynn...@gmail.com, Apr 24 2018 

Forgot to add that based on some historic data, this issue is NOT present in 65.0.3325.146. It first appears in 65.0.3325.181, and is also present in 66.0.3359.117.

You can see in the WebPageTest result that SSL timing info is missing from request #4: https://www.webpagetest.org/result/180424_1S_c424ea881ad0956e8f4028f401a404bd/1/details/#waterfall_view_step1

Comment 2 by krajshree@chromium.org, Apr 24 2018

Labels: Needs-Bisect Needs-Triage-M67

Comment 3 by phanindra.mandapaka@chromium.org, Apr 24 2018

Cc: phanindra.mandapaka@chromium.org
Labels: -Needs-Bisect Triaged_ET M-68 FoundIn-68 Target-68 OS-Mac OS-Windows
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on reported chrome version 67.0.3396.10 and on latest canary 68.0.3404.0 using Ubuntu 14.04, Windows 10 and Mac 10.13.
 Tested this on 65.0.3325.146 as per commented#1 but SSL section seems to be missing for some requests on that version as well.
 
Same behavior is seen on M60(60.0.3112.113) hence considering it as non-regression and marking it as Untriaged.

Thanks!

Comment 4 by phanindra.mandapaka@chromium.org, Apr 24 2018

Labels: -Triaged_ET Triaged-ET

Comment 5 by dgozman@chromium.org, May 21 2018

Labels: -Needs-Triage-M67 Needs-Feedback
Works for me locally. Could it be that TLS connection and/or session was reused, and therefore no new SSL handshake happened?
ssl-timing.png
105 KB View Download

Comment 6 by joewynn...@gmail.com, May 24 2018 

Argh, I had totally forgotten that Connection: keep-alive (or its absence) is irrelevant with H2. Connection reuse totally explains this. The connection timeout seems to be about 2 minutes, after which time the TLS timing shows up again.

I'm happy for this ticket to be closed as invalid.

Comment 7 by dgozman@chromium.org, May 25 2018

Status: WontFix (was: Untriaged)
I'm glad we figured this out!
►

Sign in to add a comment