I wasn't able to reproduce on Chrome 57 or 58 on Linux or 57 or 59 on Windows. Others report intermittent repro which suggests perhaps there's a race condition of some sort.

Deleted: MissingInfo.jpg 10.0 KB

	MissingInfo.jpg 10.0 KB View Download

Spoke too soon. I can repro intermittently on 59 for a different subdomain. If I use the Copy All as HAR feature in the Network tab and look for the target domain, I see a single request, for the same URL. Interestingly, if I use "Copy all as HAR", I see this request TWICE. The first request contains minimal headers and the Response has a "statusText" of "Service Worker Fallback Required". 302ms later, the request is repeated and this time it has a full set of HTTP headers and it returns a HTTP/2 response.

DevTools Network Tab hides the first request due to the status text: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/devtools/front_end/network/NetworkLogView.js?type=cs&q=%22Service+Worker+Fallback+Required%22+package:%5Echromium$&l=1409

We seem to create the "Service Worker Fallback Required" response here: https://cs.chromium.org/chromium/src/content/browser/service_worker/service_worker_url_request_job.cc?type=cs&q=%22Service+Worker+Fallback+Required%22+package:%5Echromium$&l=736


Theory-- The "first request to this domain" is reported to the Security Tab but because it doesn't actually hit the network, we don't have the connection info. When the later request actually hits the network, we've already cached the "No Certificate" on the internal data?

       "startedDateTime": "2017-03-16T14:57:35.770Z",
        "time": 0,
        "request": {
          "method": "GET",
          "url": "https://analytics.twitter.com/tpm/p?_=1489676254929",
          "httpVersion": "unknown",
          "headers": [
            {
              "name": "Accept",
              "value": "application/json, text/javascript, */*; q=0.01"
            },
            {
              "name": "Referer",
              "value": "https://twitter.com/"
            },
            {
              "name": "User-Agent",
              "value": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3042.0 Safari/537.36"
            }
          ],
          "queryString": [
            {
              "name": "_",
              "value": "1489676254929"
            }
          ],
          "cookies": [],
          "headersSize": -1,
          "bodySize": 0
        },
        "response": {
          "status": 400,
          "statusText": "Service Worker Fallback Required",
          "httpVersion": "unknown",
          "headers": [],
          "cookies": [],
          "content": {
            "size": 0,
            "mimeType": "text/plain"
          },
          "redirectURL": "",
          "headersSize": -1,
          "bodySize": 0,
          "_transferSize": 0
        },
        "cache": {},
        "timings": {
          "blocked": -1,
          "dns": -1,
          "connect": -1,
          "send": 0,
          "wait": 0,
          "receive": 0,
          "ssl": -1
        },
        "serverIPAddress": "",
        "pageref": "page_1"
      },

Deleted: Repro-on-59_3042.png 30.2 KB

	Repro-on-59_3042.png 30.2 KB View Download

Interestingly, Emily seems to be able to repro this without ServiceWorker.

In the failing cases, _processRequest is first getting called with a securityState of unknown and a securityDetails() of null. This gets cached in our data structures and prevents later calls from storing a real set of securityDetails(). The "cheap" fix would be to update the securityDetails if they were previously null, e.g.

  if (oldSecurityState !== originState.securityState) {
    this._sidebarTree.updateOrigin(origin, securityState);
    if (originState.originView)
      originState.originView.setSecurityState(securityState);
+   if (!originState.securityDetails) {
+     let securityDetails = request.securityDetails();
+     if (securityDetails) {
+       originState.securityDetails = securityDetails;
+     }
+   }
  }

... but this isn't a root cause fix, insofar as if there's no followup request that has securityDetails(), we won't correct the UI. Because we don't know how we end up with the "securityState: unknown" requests coming into this codepath, we don't yet know whether it's possible that the request with missing data could ever not have a subsequent request with correct data.

Currently our behavior around not-updating securityDetails seems wrong. For instance, if you come in with SecurityState.Secure, we cache those securityDetails on the origin.

Then, if a later request ends up with SecurityState.Insecure or whatever, we update the securityState on that origin, but leave the securityDetails as they were for the prior state. So we might show an Insecure state with perfectly valid connection info.

So maybe we ought to be doing:

  if (oldSecurityState !== originState.securityState) {
        this._sidebarTree.updateOrigin(origin, securityState);
        if (originState.originView)
          originState.originView.setSecurityState(securityState);
+      let securityDetails = request.securityDetails();
+      if (securityDetails) {
+           originState.securityDetails = securityDetails;
+       }
      }

...even if we also fix the root cause (sometimes omitting securityDetails() when processRequest gets called) of this Issue in another way.

We think Emily's repro is where the request originally went into the memory cache (without security info) before the DevTools opened.

In my repro, this appears to have a root cause of a TODO in service_worker_context_client.cc code:

// TODO(horo): Set report_security_info to true when DevTools is attached. const bool report_security_info = false; WebURLLoaderImpl::PopulateURLResponse(url_, response_head, response_.get(), report_security_info);

yoink

https://codereview.chromium.org/2763563003/

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

commit 3ef0a6666394621ad4874522b05ac00dce9342fc
Author: elawrence <elawrence@chromium.org>
Date: Tue Mar 21 21:45:38 2017

[DevTools] Update SecurityDetails in Security panel if State changes

When the SecurityState for an origin changes, update the Security
Details for that origin as well. This mitigates scenarios where the
Details may not have been available initially (e.g. an image pulled
from the MemoryCache without the Developer Tools loaded will not have
any SecurityDetails recorded.

BUG= 702001 
TEST=blink_layouttests security-details-updated-with-security-state

Review-Url: https://codereview.chromium.org/2763563003
Cr-Commit-Position: refs/heads/master@{#458562}

[add] https://crrev.com/3ef0a6666394621ad4874522b05ac00dce9342fc/third_party/WebKit/LayoutTests/http/tests/inspector/security/security-details-updated-with-security-state-expected.txt
[add] https://crrev.com/3ef0a6666394621ad4874522b05ac00dce9342fc/third_party/WebKit/LayoutTests/http/tests/inspector/security/security-details-updated-with-security-state.html
[modify] https://crrev.com/3ef0a6666394621ad4874522b05ac00dce9342fc/third_party/WebKit/Source/devtools/front_end/security/SecurityPanel.js