[2/3 chromium] Support redirect option of Request and "opaqueredirect" response type.

content/browser/loader/resource_loader.cc

Index: content/browser/loader/resource_loader.cc
diff --git a/content/browser/loader/resource_loader.cc b/content/browser/loader/resource_loader.cc
index 0339cf11c0d5ade2f2f4ebe14a64cd3da4289c3b..0a214a8ddadc1229ac40a7664899e26856979772 100644
--- a/content/browser/loader/resource_loader.cc
+++ b/content/browser/loader/resource_loader.cc
@@ -280,6 +280,29 @@ void ResourceLoader::OnReceivedRedirect(net::URLRequest* unused,
     return;
   }
 
+  if (info->fetch_redirect_mode() == FETCH_REDIRECT_MODE_ERROR) {
+    Cancel();
+    return;
+  } else if (info->fetch_redirect_mode() == FETCH_REDIRECT_MODE_MANUAL) {
+    // TODO(horo): If we support upload progress events for Fetch API, we will
+    // have to call ReportUploadProgress().
+    DCHECK(!GetRequestInfo()->is_upload_progress_enabled());
+
+    CompleteResponseStarted(true);
+    if (is_deferred())
+      return;
+
+    // There is no need to read the response body here because there is no way
+    // to read the body of opaque-redirect filtered response's internal
+    // response.
+    // TODO(horo): If we support any API which expose the internal body, we will
+    // have to read the body before calling ResponseCompleted(). And also Cache
+    // changes will be needed because it doesn't store the body of redirect
+    // responses.
+    ResponseCompleted();
+    return;
+  }
+
   delegate_->DidReceiveRedirect(this, redirect_info.new_url);
 
   if (delegate_->HandleExternalProtocol(this, redirect_info.new_url)) {
@@ -389,7 +412,7 @@ void ResourceLoader::OnResponseStarted(net::URLRequest* unused) {
     ReportUploadProgress();
   }
 
-  CompleteResponseStarted();
+  CompleteResponseStarted(false);
 
   if (is_deferred())
     return;
@@ -582,7 +605,7 @@ void ResourceLoader::CancelRequestInternal(int error, bool from_renderer) {
   }
 }
 
-void ResourceLoader::CompleteResponseStarted() {
+void ResourceLoader::CompleteResponseStarted(bool is_redirect_response) {
   ResourceRequestInfoImpl* info = GetRequestInfo();
   scoped_refptr<ResourceResponse> response(new ResourceResponse());
   PopulateResourceResponse(info, request_.get(), response.get());
@@ -611,7 +634,9 @@ void ResourceLoader::CompleteResponseStarted() {
     Cancel();
   } else if (defer) {
     read_deferral_start_time_ = base::TimeTicks::Now();
-    deferred_stage_ = DEFERRED_READ;  // Read first chunk when resumed.
+    // Complete when resumed for redirect responses, otherwise read first chunk.
+    deferred_stage_ =
+        is_redirect_response ? DEFERRED_RESPONSE_COMPLETE : DEFERRED_READ;

[mmenke, 2015/08/11 18:48:56]

In this new path, we skip both OnWillRead and OnReadComplete(0), which
ResourceHandlers normally see for all successes.  I'm very concerned that this
new path will subtly break some ResourceHandler in a hard to debug manner.  And
I'm even more concerned that I'll end up being the one stuck with investigating
it, 2 months down the line when it suddenly turns up on stable as a mysterious
network crash.  Or 2 years down the line, when someone starts using
redirect_mode for something else entirely, using a different ResourceHandler
stack.

I think we could safely remove the 0-byte OnReadComplete(0) after the final read
everywhere, but then there's still the OnWillRead call we're skipping.

   }
 }