PlzNavigate: Add missing Upgrade-Insecure-Requests header.

content/browser/frame_host/navigation_request.cc

Index: content/browser/frame_host/navigation_request.cc
diff --git a/content/browser/frame_host/navigation_request.cc b/content/browser/frame_host/navigation_request.cc
index ddbc83136f8991d8655256ef4630aaa3bf83e05c..23eccb1b27444f3a1ad937f5670299cd5d386b84 100644
--- a/content/browser/frame_host/navigation_request.cc
+++ b/content/browser/frame_host/navigation_request.cc
@@ -126,6 +126,11 @@ void AddAdditionalRequestHeaders(net::HttpRequestHeaders* headers,
 
   headers->SetHeaderIfMissing(net::HttpRequestHeaders::kUserAgent,
                               GetContentClient()->GetUserAgent());
+
+  // Tack an 'Upgrade-Insecure-Requests' header to outgoing navigational

[clamy, 2016/11/02 14:01:30]

This is called also for subframe navigations, is this the expected behavior?

[arthursonzogni, 2016/11/02 16:55:28]

Yes it is.
The browser-side implementation is putting the header for every navigational
requests: 
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/loader/Fr...

In contrast, the specification is a little bit different:
https://w3c.github.io/webappsec-upgrade-insecure-requests/#preference
It defines when the header must be there and when it should be defined, but not
when it must not be defined.

For subframe navigation, the header might already have been defined by the
renderer before being intercepted by PlzNavigate. In that case, this is a no-op.
In the future, I plan to upgrade navigational request on the browser and not
rely on the renderer (e.g: reverting my first patch:
https://codereview.chromium.org/2284683002/). In that case, this will no more be
a no-op.

+  // requests, as described in
+  // https://w3c.github.io/webappsec/specs/upgrade/#feature-detect
+  headers->AddHeaderFromString("Upgrade-Insecure-Requests: 1");
 }
 
 }  // namespace