Add plumbing for allowing the renderer to intercept and cancel redirects before

they are sent.

A good portion of this CL is to support the new UI test.

The IPC to notify the renderer of a redirect now includes a ResponseInfo struct
allowing WebURLLoaderImpl to provide detailed response info (including response
headers) to WebKit.  This isn't strictly necessary, but I thought I'd include
this to make the code more future proof.

A cross origin restriction is added to SyncResourceHandler::OnRequestRedirected
that mimics the code in WebCore/platform/network/cf/ResourceHandleCFNet.cpp.
This is most unfortunate, and I filed a bug at bugs.webkit.org about the
similar duplication of logic in WebCore.

There seemed to be enough code paths leading to request cancellation at the
ResourceDispatcher level that I couldn't easily ensure that a request only gets
cancelled once.  So, I added an is_cancelled flag to record if it is not
necessary to send a ViewHostMsg_CancelRequest IPC.  This avoids some warnings
in the ResourceDispatcherHost.

To support my UI test, I needed to change URLRequestMockHttpJob to know how to
serve redirects.  I moved URLRequestHttpJob::IsRedirectResponse to its base
class, URLRequestJob so that the implementation could be shared.  This revealed
a minor bug in URLRequest.  We were never resetting response_info_ upon
following a redirect.  I added this code consolidated similar code from
URLRequest::Redirect and URLRequest::RestartWithJob into a new PrepareToRestart
method.

To support my UI test, I added a "hit count" field to URLRequestFilter, and I
added an associated automation IPC to query the value.  The test was a bit
challenging to write because there is no way to tell the difference from JS.
Before and after, it appears to JS as though the cross-origin redirect failed.
However, the server can see the extra redirect request.  So, I simply record
the number of hits against URLs of the form http://mock.http/foo, and use that
to observe if any extra requests were made.  I implemented the new IPC message
by extending the AutomationResourceMessageFilter.  This allowed me to trap the
IPC message on the IO thread where it is safe to probe the URLRequestFilter.  I
then changed the implementation of AutomationMsg_SetFilteredInet to work
similarly.

I revised URLRequestMockHTTPJob::GetOnDiskPath to support ports.  This actually
allowed me to reuse URLRequestMockHTTPJob to service URLs in different security
origins.  My test redirects from http://mock.http/ to http://mock.http:4000/.

Please see the comments in cross-origin-redirect-blocked.html for details about
how the test functions.

R=brettw,wtc
BUG=16413
TEST=covered by resource_dispatcher_host_uitest.cc

Review URL: http://codereview.chromium.org/159370

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22067 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 4 insertions, 1 deletions

diff --git a/chrome/plugin/chrome_plugin_host.cc b/chrome/plugin/chrome_plugin_host.cc
index 81a128a..a5c7dfa 100644
--- a/chrome/plugin/chrome_plugin_host.cc
+++ b/chrome/plugin/chrome_plugin_host.cc
@@ -66,9 +66,12 @@ class PluginRequestHandlerProxy
       upload_progress(cprequest_.get(), position, size);
   }
 
-  virtual void OnReceivedRedirect(const GURL& new_url) {
+  virtual bool OnReceivedRedirect(
+      const GURL& new_url,
+      const ResourceLoaderBridge::ResponseInfo& info) {
     plugin_->functions().response_funcs->received_redirect(
         cprequest_.get(), new_url.spec().c_str());
+    return true;
   }
 
   virtual void OnReceivedResponse(