Revert r143458 (which re-applies r143341 and r142979). This CL also includes

unit tests for DataReceived and DataReceived_ACK messaging.

Make ResourceHandlers that defer loading also be responsible for calling Resume
on their ResourceController.

What this does is avoid out-of-band calls to Resume the ResourceLoader, and
that means that an intermediate ResourceHandler (for example the
BufferedResourceHandler) will be able to implement ResourceController.

Consider the problematic scenerio that happens today:

1- The BufferedResourceHandler consumes response headers and buffers network
data, delaying notifications to its downstream ResourceHandler.
2- The BufferedResourceHandler decides if it is dealing with a download or
not, and optionally installs a DownloadResourceHandler as the downstream
handler.
3- The BufferedResourceHandler replays the OnResponseStarted and
OnReadCompleted events to push data to its downstream handler.
4- The downstream handler might decide to defer processing.
5- When the downstream handler wants to resume processing, it needs to
tell someone to Resume.

At step 5, the complicated thing we do to ourselves today is we make that
Resume step tell the ResourceLoader to resume instead of the
BufferedResourceHandler.

This causes problems for the BufferedResourceHandler as it may start receiving
more network events before it has finished flushing its existing buffers to its
downstream handler.

This patch is a step toward fixing the above problem. It makes all handlers
call Resume on their own controller when it is time to resume. A subsequent
patch will leverage this to cleanup and simplify the BufferedResourceHandler
as well as the overall pause/resume semantics of the ResourceLoader.

Other cleanup in this patch: The {Async,Sync,CrossSite}ResourceHandler
classes are now all constructed with an URLRequest. This avoids messy
code to call ResourceDispatcherHostImpl::GetURLRequest(). Since the
lifetime of ResourceHandlers is now bound to the lifetime of their
associated URLRequest, this is a safe and simple change to make. Other
ResourceHandlers, like the BufferedResourceHandler, were already holding
onto their associated URLRequest.

R=jam@chromium.org
Review URL: https://chromiumcodereview.appspot.com/10644011

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

1 files changed, 1 insertions, 1 deletions

diff --git a/content/browser/renderer_host/resource_request_info_impl.cc b/content/browser/renderer_host/resource_request_info_impl.cc
index 501d3f0..c063d1d 100644
--- a/content/browser/renderer_host/resource_request_info_impl.cc
+++ b/content/browser/renderer_host/resource_request_info_impl.cc
@@ -98,6 +98,7 @@ ResourceRequestInfoImpl::ResourceRequestInfoImpl(
     WebKit::WebReferrerPolicy referrer_policy,
     ResourceContext* context)
     : cross_site_handler_(NULL),
+      async_handler_(NULL),
       process_type_(process_type),
       child_id_(child_id),
       route_id_(route_id),
@@ -107,7 +108,6 @@ ResourceRequestInfoImpl::ResourceRequestInfoImpl(
       frame_id_(frame_id),
       parent_is_main_frame_(parent_is_main_frame),
       parent_frame_id_(parent_frame_id),
-      pending_data_count_(0),
       is_download_(is_download),
       allow_download_(allow_download),
       has_user_gesture_(has_user_gesture),