Plumb redirect info out of net, through content, and into child processes.

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 2957728545e30adee24c804af29e71a7cf2d45a8..58246f6a0fe1a6acc946d5b884e63dfc7b6906b7 100644
--- a/content/browser/loader/resource_dispatcher_host_impl.cc
+++ b/content/browser/loader/resource_dispatcher_host_impl.cc
@@ -528,6 +528,15 @@ DownloadInterruptReason ResourceDispatcherHostImpl::BeginDownload(
   }
   request->SetLoadFlags(request->load_flags() | extra_load_flags);
 
+  // We treat a download as a main frame load, and thus update the policy URL on
+  // redirects.
+  //
+  // TODO(davidben): Is this correct? If this came from a
+  // ViewHostMsg_DownloadUrl in a frame, should it have first-party URL set
+  // appropriately?
+  request->set_first_party_url_policy(
+      net::URLRequest::UPDATE_FIRST_PARTY_URL_ON_REDIRECT);

[davidben, 2014/07/17 22:03:55]

This is from download_resource_handler. Given that those requests never get
first-party URLs set to begin with, I suspect this is a no-op, modulo
differences between empty first-party URLs and first-party requests. (From when
I tried to make first-party request <=> empty first-party URL and avoid this
policy bit.)

[mmenke, 2014/07/18 15:18:36]

They don't get first party URLs?  What if we don't know its a download until we
get (Or sniff) the mime-type?  Speaking of that case...  What about when
BufferedResourceHandler begins a download?  It doesn't go through this code, I
believe...  Though I suppose at that point, there won't be any redirects, and
the we can set the policy, anyways, since the request is still pending...

[davidben, 2014/07/18 16:14:58]

Sorry, that was unclear. There's two codepaths for downloads.

1. A normal navigation request that the BRH redirects to a
DownloadResourceHandler.

2. A request that began as a download in RDH::BeginDownload.

For 1, neither the old code nor the new code did anything. This codepath doesn't
hit BeginDownload and the DRH never sees the redirect. It gets its first-party
URL and now the first-party URL policy (in the old code, the
CrossSiteResourceHandler implemented that policy) from the same codepath that
sets them for other resources.

For 2, we hit this codepath. The old code never set a first-party URL which is
probably wrong, but I've left it as-is for this CL. It also would go through
RDH::BeginDownload which would implement UPDATE_FIRST_PARTY_URL_ON_REDIRECT, so
this new logic mirrors that. I suspect we actually should be setting these based
on the owning frame (does <a download> go through this codepath?) and never set
UPDATE_FIRST_PARTY_URL_ON_REDIRECT, but I've retained the existing behavior for
now.

+
   // Check if the renderer is permitted to request the requested URL.
   if (!ChildProcessSecurityPolicyImpl::GetInstance()->
           CanRequestURL(child_id, url)) {
@@ -1052,6 +1061,13 @@ void ResourceDispatcherHostImpl::BeginRequest(
   new_request->set_first_party_for_cookies(
       request_data.first_party_for_cookies);
 
+  // If the request is a MAIN_FRAME request, the first-party URL gets updated on
+  // redirects.
+  if (request_data.resource_type == ResourceType::MAIN_FRAME) {
+    new_request->set_first_party_url_policy(
+        net::URLRequest::UPDATE_FIRST_PARTY_URL_ON_REDIRECT);
+  }
+
   const Referrer referrer(request_data.referrer, request_data.referrer_policy);
   SetReferrerForRequest(new_request.get(), referrer);