Initial PlzNavigate RDH-side logic.

content/browser/loader/stream_writer.cc

+// Copyright 2014 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "content/browser/loader/stream_writer.h"
+
+#include "base/guid.h"
+#include "content/browser/streams/stream.h"
+#include "content/browser/streams/stream_registry.h"
+#include "content/public/browser/resource_controller.h"
+#include "net/base/io_buffer.h"
+#include "url/gurl.h"
+#include "url/url_constants.h"
+
+namespace content {
+
+StreamWriter::StreamWriter() {
+}
+
+StreamWriter::~StreamWriter() {
+  if (stream_.get())
+    Finalize();
+}
+
+void StreamWriter::InitializeStream(StreamRegistry* registry,
+                                    const GURL& origin) {
+  DCHECK(!stream_.get());
+
+  // TODO(tyoshino): Find a way to share this with the blob URL creation in
+  // WebKit.
+  GURL url(std::string(url::kBlobScheme) + ":" + origin.spec() +
+           base::GenerateGUID());

[mmenke, 2014/09/23 17:22:45]

Erm...Wait...So after navigation occurs, we redirect the request to a blob URL? 
I guess we then pass that to the correct renderer process, and have it read from
that, instead of taking ownership of the original loader?

[davidben, 2014/10/03 16:27:53]

Yeah. We're going to get the flow working this way first because it minimizes
the churn Blink-side. This way Blink still makes a normal request and most of
Blink-side navigation logic can continue to go through its resource loader.

Once all that works, we'll try to disentangle the two and Blink can be passed
some kind of handle to the body directly. (Shared memory segment, Mojo data
pipe, etc.) But hopefully browser-side it'll still have the same structure: make
request, get response headers + some handle to the body back. Handle to body can
be passed down to a process.

+  stream_ = new Stream(registry, this, url);
+}
+
+void StreamWriter::OnWillRead(scoped_refptr<net::IOBuffer>* buf,
+                              int* buf_size,
+                              int min_size) {
+  static const int kReadBufSize = 32768;

[mmenke, 2014/09/23 17:22:46]

Can static const int result in something first being initialized on the first
call to a function or not?  I know this has been discussed, just can never
remember what the conclusion was.

[davidben, 2014/10/03 16:27:53]

I would expect it to be fine. At least, we do do it everywhere. :-) I just
pulled it from StreamResourceHandler. Can switch it too, *shrug*.

+
+  DCHECK(buf && buf_size);

[mmenke, 2014/09/23 17:22:46]

nit:  Use two DCHECKs.  The one for buf_size should probably be
DCHECK_GT(buf_size, 0)

[davidben, 2014/10/03 16:27:53]

Done. (Except buf_size is a pointer, so still just a DCHECK.)

+  if (!read_buffer_.get())
+    read_buffer_ = new net::IOBuffer(kReadBufSize);
+  *buf = read_buffer_.get();
+  *buf_size = kReadBufSize;
+}
+
+void StreamWriter::OnReadCompleted(int bytes_read, bool* defer) {
+  if (!bytes_read)
+    return;
+
+  // We have more data to read.
+  DCHECK(read_buffer_.get());
+
+  // Release the ownership of the buffer, and store a reference
+  // to it. A new one will be allocated in OnWillRead().
+  scoped_refptr<net::IOBuffer> buffer;
+  read_buffer_.swap(buffer);
+  stream_->AddData(buffer, bytes_read);
+
+  if (!stream_->can_add_data())
+    *defer = true;
+}
+
+void StreamWriter::Finalize() {
+  DCHECK(stream_.get());
+  stream_->Finalize();
+  stream_->RemoveWriteObserver(this);
+  stream_ = NULL;
+}
+
+void StreamWriter::OnSpaceAvailable(Stream* stream) {
+  controller_->Resume();
+}
+
+void StreamWriter::OnClose(Stream* stream) {
+  controller_->Cancel();
+}
+
+}  // namespace content