Create blobs from Disk Cache entries.

content/browser/loader/upload_data_stream_builder.cc

Index: content/browser/loader/upload_data_stream_builder.cc
diff --git a/content/browser/loader/upload_data_stream_builder.cc b/content/browser/loader/upload_data_stream_builder.cc
index c497c16c0a769ea50c20469ba1fc44e47708dc31..2f63c231600e871f1e78b5522bfb5ac51f56aaf5 100644
--- a/content/browser/loader/upload_data_stream_builder.cc
+++ b/content/browser/loader/upload_data_stream_builder.cc
@@ -135,6 +135,11 @@ scoped_ptr<net::UploadDataStream> UploadDataStreamBuilder::Build(
         // TODO(dmurph): Create blob reader and store the snapshot in there.
         NOTREACHED();
         break;
+      case ResourceRequestBody::Element::TYPE_DISK_CACHE_ENTRY:
+        // Disk cache entries should not be uploaded, instead only requested
+        // from blink.

[mmenke, 2015/06/12 18:52:42]

Are you sure this comment about them being requested from blink is right?  If we
can't send them via IPCs, to or from blink, and they're created in the renderer
process...I'm not following how these interact at all with blink.

Admittedly, I know next to nothing about blobs (loader/ is such a catch all of
random cruft that it has a lot of code I really don't know, most of it poorly
documented, to boot)

[michaeln, 2015/06/12 23:43:06]

Once something in blink has a Blob backed by a disk cache entry, what's to
prevent it from uploading?

cache.match(x).then(function(response) {
    xhr.send(response.body)
    ...
  });

[gavinp, 2015/06/15 14:01:19]

Ahhh, OK. So right now I think this is safe, because all of the mechanisms to
move blobs from the renderer process to the browser process do it by copying the
whole thing in to RAM, but yes, once we have enabled that functionality we'll
need it. Should that be in this CL, or the follow-up CL that adds the
blink-to-browser process movement of response bodies?

[gavinp, 2015/06/15 14:01:19]

Blobs are a mess as well; in particular, blobs have an IPC mechanism, but
basically never use it for transfers from the browser process to the renderer
process, as near as I can tell (dmurph and michaeln can explain this more).
Instead, they are sent via their blob uuid from the browser to the renderer
process, and a blob_url_request_job is consed up to request the blob's contents
when needed.

+        NOTREACHED();
+        break;
       case ResourceRequestBody::Element::TYPE_UNKNOWN:
         NOTREACHED();
         break;