Create blobs from Disk Cache entries.

content/browser/loader/upload_data_stream_builder.cc

 // Copyright 2013 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/upload_data_stream_builder.h"
 
 #include "base/logging.h"
 #include "content/browser/fileapi/upload_file_system_file_element_reader.h"
 #include "content/common/resource_request_body.h"
 #include "net/base/elements_upload_data_stream.h"
@@ skipping 117 matching lines @@
                 element.filesystem_url(),
                 element.offset(),
                 element.length(),
                 element.expected_modification_time()));
         break;
       case ResourceRequestBody::Element::TYPE_BLOB:
         // Blob elements should be resolved beforehand.
         // 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;
     }
   }
 
   return make_scoped_ptr(
       new net::ElementsUploadDataStream(element_readers.Pass(),
                                         body->identifier()));
 }
 
 }  // namespace content