Implement Drain() on HttpPipelinedStream.

net/http/http_pipelined_stream.cc

Index: net/http/http_pipelined_stream.cc
diff --git a/net/http/http_pipelined_stream.cc b/net/http/http_pipelined_stream.cc
index 6b844a6210ddae7eb0f3ca8d16c29fe9d6c290af..b281f4f132d03fa4ec9e791eeaae3e20881d3fcd 100644
--- a/net/http/http_pipelined_stream.cc
+++ b/net/http/http_pipelined_stream.cc
@@ -10,6 +10,9 @@
 #include "net/http/http_pipelined_connection_impl.h"
 #include "net/http/http_request_headers.h"
 #include "net/http/http_request_info.h"
+#include "net/http/http_response_body_drainer.h"
+#include "net/http/http_response_headers.h"
+#include "net/http/http_response_info.h"
 #include "net/http/http_util.h"
 
 namespace net {
@@ -118,11 +121,18 @@ void HttpPipelinedStream::LogNumRttVsBytesMetrics() const {
   // TODO(simonjam): I don't want to copy & paste this from http_basic_stream.
 }
 
-void HttpPipelinedStream::Drain(HttpNetworkSession*) {
-  // On errors, we already evict everything from the pipeline and close it.
-  // TODO(simonjam): Consider trying to drain the pipeline in the same way that
-  // HttpBasicStream does.
-  delete this;
+void HttpPipelinedStream::Drain(HttpNetworkSession* session) {

[willchan no longer on Chromium, 2011/11/20 18:09:21]

I sort of suspect we want to defer the actual drain logic to the underlying
|pipeline_|, since it can probably make a better decision. It'll know how deep
the pipeline is. I guess the deeper the pipeline, the less willing we should be
to throw away the connection.

[James Simonsen, 2011/11/22 01:24:20]

Done.

+  if (!CanFindEndOfResponse()) {
+    // TODO(simonjam): It may be faster to drain the entire pipeline and re-use
+    // the connection than to close it and start over.

[mmenke, 2011/11/18 15:45:38]

nit:  Think we don't need this TODO any more, unless you mean in the case that
we've only sent out one request over the wire.

[James Simonsen, 2011/11/22 01:24:20]

I want to be able to recover without calling Close(true), which will disconnect
the socket. That means evicting everything, draining all of the content, but
leaving the socket usable.

I'm not sure that's even something we can do reliably though. For instance, we
might have front-of-queue blocking on one of the responses and assume we've
drained it all, only to get the rest of the response after we restart the
pipeline.

I think I've talked myself out of this now, so yeah, I'll delete that comment.

+    Close(true);
+    delete this;
+    return;
+  }
+  HttpResponseBodyDrainer* drainer = new HttpResponseBodyDrainer(this);
+  drainer->StartWithSize(session,
+                         GetResponseInfo()->headers->GetContentLength());

[mmenke, 2011/11/18 15:45:38]

Important:  This doesn't work with chunked encoding.  We'll need a test for
that, too.

Cancelled or otherwise in-need-of-draining chunk-encoded requests may be rare
enough that we can just cancel the transfer, first pass, and worry about doing
something smart in another CL.  Or you can try and handle it in this one, up to
you.  May require a fair bit of work to handle correctly, I'm not familiar with
the specifics.

[James Simonsen, 2011/11/22 01:24:20]

Thanks. Didn't know anything about chunked encoding. I'm going to pass on diving
in right now. Sometime later, I'll add a metric to see how often this happens in
the wild and decide whether or not we should tackle it.

+  // |drainer| will delete itself when done.
 }
 
 const SSLConfig& HttpPipelinedStream::used_ssl_config() const {