WIP: Move 'Upgrade-Insecure-Requests' to the browser process.

content/browser/loader/resource_dispatcher_host_impl.cc

Index: content/browser/loader/resource_dispatcher_host_impl.cc
diff --git a/content/browser/loader/resource_dispatcher_host_impl.cc b/content/browser/loader/resource_dispatcher_host_impl.cc
index 50153c6706bfa0951f8506161aa063702a7069b1..9b34213b12e5f78b1e344f6767170edd07be7f3b 100644
--- a/content/browser/loader/resource_dispatcher_host_impl.cc
+++ b/content/browser/loader/resource_dispatcher_host_impl.cc
@@ -119,6 +119,8 @@
 #include "storage/browser/blob/shareable_file_reference.h"
 #include "storage/browser/fileapi/file_permission_policy.h"
 #include "storage/browser/fileapi/file_system_context.h"
+#include "third_party/WebKit/public/platform/WebInsecureRequestPolicy.h"
+#include "ui/base/page_transition_types.h"
 #include "url/url_constants.h"
 
 using base::Time;
@@ -1469,6 +1471,10 @@ void ResourceDispatcherHostImpl::BeginRequest(
   new_request->set_first_party_for_cookies(
       request_data.first_party_for_cookies);
   new_request->set_initiator(request_data.request_initiator);
+  if (request_data.insecure_request_policy & blink::kUpgradeInsecureRequests) {
+    new_request->set_insecure_request_policy(
+        net::URLRequest::UPGRADE_ALL_INSECURE_REQUESTS);

[mmenke, 2016/06/09 18:56:55]

Does this have to be a member of the URLRequest?.  It seems like there are at
least two other options here:

1)  Make it a member of the lovely struct ResourceRequestInfoImpl (Which can be
grabbed from a URLRequest).
2)  URLRequest implements SupportsUserData, so could set it that way.

We could add it to URLRequest::GetHSTSRedirect, as you suggest.  My concerns
there are the scope of URLRequest's API (Which is constantly growing, and
eventually may grow to encompass the entire Chrome code base), in addition to
whether or not it belongs there.

On the other hand, set up here is more than a little obscure, since we have to
go through StoragePartition, which isn't great.

I think either of those options are better than the other browser-based options
(Modifying RedirectInfo, for the API/correctness reasons already mentioning, or
do what extensions do - which is much along the same lines as modifying
RedirectInfo, I believe - though they do it from the NetworkDelegate interface
instead).

[Mike West, 2016/06/10 09:55:16]

This seems like the best approach if you want to keep it out of URLRequest.
If we have to resort to SupportsUserData, I feel like we're just admitting that
we'd rather be lazy than design a reasonable solution. :) I mean, I _am_ lazy,
but I'd like not to admit it so publicly!
I think there's a case to be made for stuffing it into URLRequest, however, as
it's really triggering the same behavior as `URLRequest::GetHSTSRedirect`. It
would be nice to merge those together, and pulling HSTS out of URLRequest seems
like the wrong way to do it.

I agree that it's increasing the scope of URLRequest, but since it's not
actually adding a new feature, just giving the caller another way of triggering
existing behavior, it seems like a pretty minor expansion.
Right. If you hadn't explicitly suggested looking at `URLRequestInterceptor`, I
don't think I'd have found this mechanism. That's not fatal, of course, but it
is something to consider.
I defer to you on this; you have a much better picture of what you'd like the
API to be than I do.

+  }
 
   if (request_data.originated_from_service_worker) {
     new_request->SetUserData(URLRequestServiceWorkerData::kUserDataKey,
@@ -2238,6 +2244,16 @@ void ResourceDispatcherHostImpl::BeginNavigationRequest(
   new_request->set_first_party_for_cookies(
       info.first_party_for_cookies);
   new_request->set_initiator(info.request_initiator);
+  if (info.should_upgrade_to_secure_transport) {
+    net::URLRequest::InsecureRequestPolicy policy =
+        net::URLRequest::UPGRADE_ALL_INSECURE_REQUESTS;
+    if (info.is_main_frame &&
+        info.common_params.transition !=
+            ui::PageTransition::PAGE_TRANSITION_FORM_SUBMIT) {
+      policy = net::URLRequest::UPGRADE_SAME_HOST_INSECURE_REQUESTS;
+    }
+    new_request->set_insecure_request_policy(policy);
+  }

[mmenke, 2016/06/14 18:49:31]

I'm not following how the "UPGRADE_SAME_HOST_INSECURE_REQUESTS" logic.  There's
mention of an "upgrade insecure navigations set", but I'm not following a word
of the description for how the "insecure navigations set" is created, and have
no idea how all that maps to "UPGRADE_SAME_HOST_INSECURE_REQUESTS".

   if (info.is_main_frame) {
     new_request->set_first_party_url_policy(
         net::URLRequest::UPDATE_FIRST_PARTY_URL_ON_REDIRECT);