From 6568a9e384e0f92422c68d4f31fb401df4acbaed Mon Sep 17 00:00:00 2001 From: "darin@chromium.org" Date: Thu, 30 Jul 2009 18:01:39 +0000 Subject: 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 --- chrome/plugin/chrome_plugin_host.cc | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'chrome/plugin') 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( -- cgit v1.1