Move first-party cookie URL logic to browser process.

content/browser/loader/async_resource_handler.cc

Index: content/browser/loader/async_resource_handler.cc
diff --git a/content/browser/loader/async_resource_handler.cc b/content/browser/loader/async_resource_handler.cc
index 7e3bd2ef99d5ef2bf030ced5a4ddcebcfa8b35b5..886c49a88ff761dc2ab13c2f48c217e14906cc3d 100644
--- a/content/browser/loader/async_resource_handler.cc
+++ b/content/browser/loader/async_resource_handler.cc
@@ -108,18 +108,12 @@ bool AsyncResourceHandler::OnMessageReceived(const IPC::Message& message,
   return handled;
 }
 
-void AsyncResourceHandler::OnFollowRedirect(
-    int request_id,
-    bool has_new_first_party_for_cookies,
-    const GURL& new_first_party_for_cookies) {
+void AsyncResourceHandler::OnFollowRedirect(int request_id) {
   if (!request()->status().is_success()) {
     DVLOG(1) << "OnFollowRedirect for invalid request";
     return;
   }
 
-  if (has_new_first_party_for_cookies)
-    request()->set_first_party_for_cookies(new_first_party_for_cookies);
-
   ResumeIfDeferred();
 }
 
@@ -164,8 +158,13 @@ bool AsyncResourceHandler::OnRequestRedirected(int request_id,
   reported_transfer_size_ = 0;
   response->head.request_start = request()->creation_time();
   response->head.response_start = TimeTicks::Now();
+  // TODO(davidben): Is it necessary to pass the new first party URL for
+  // cookies? The only case where it can change is top-level navigation requests
+  // and hopefully those will eventually all be owned by the browser. It's
+  // possible this is still needed while renderer-owned ones exist.

[davidben, 2014/05/05 23:32:41]

I actually wouldn't be too surprised if this could be dropped right now, but I'm
not sure. It depends on if any renderer-side consumer of a MAIN_FRAME request
reads firstPartyFromCookies(). If we don't do this, the value in the renderer
will be wrong, but it's possible nothing reads it.

This is probably safer until we make it so that renderers never see a pre-commit
MAIN_FRAME request so that renderers don't contain known-wrong state about a
request.

I can also look at all the callers and verify that nothing cares.

[Charlie Reis, 2014/05/08 20:43:21]

I don't know the uses of that value myself, so it might be nice to check whether
it's used in that way.  Of course, that could be done for a second CL to remove
this.

[davidben, 2014/05/09 22:08:04]

Part of the use is for the DCHECK, but now that the DCHECK has cleared the bots,
I can remove both the DCHECK and this bit.

I'm tempted to err on the side of not having wrong data in the renderer, just in
case we miss something; after the rest of the work is done, we'll know we can
remove it because the only case that changes the URL is a top-level navigation
request. If we get to the point that such a request is never attached to a
renderer until it commits, we'll know there's nothing to update.

In the meantime, since we're just pushing data down to the renderer, I would
expect that it wouldn't make the project any more difficult than pushing the new
URL down does, and we'll have to deal with that anyway.

   return info->filter()->Send(new ResourceMsg_ReceivedRedirect(
-      request_id, new_url, response->head));
+      request_id, new_url, request()->first_party_for_cookies(),
+      response->head));
 }
 
 bool AsyncResourceHandler::OnResponseStarted(int request_id,