Initial PlzNavigate RDH-side logic.

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/upload_bytes_element_reader.h"
@@ skipping 97 matching lines @@
     const ResourceRequestBody::Element& element = *resolved_elements[i];
     switch (element.type()) {
       case ResourceRequestBody::Element::TYPE_BYTES:
         element_readers.push_back(new BytesElementReader(body, element));
         break;
       case ResourceRequestBody::Element::TYPE_FILE:
         element_readers.push_back(
             new FileElementReader(body, file_task_runner, element));
         break;
       case ResourceRequestBody::Element::TYPE_FILE_FILESYSTEM:
-        element_readers.push_back(
-            new content::UploadFileSystemFileElementReader(
-                file_system_context,
-                element.filesystem_url(),
-                element.offset(),
-                element.length(),
-                element.expected_modification_time()));
+        if (file_system_context) {

[clamy, 2014/09/12 20:51:26]

Is this change there because we may not have supplied a FileSystemContext when
sending a navigation request from the UI thread?

[davidben, 2014/09/19 18:30:50]

Yeah. For now we don't supply one at all. This is the comment in RDH:

    // TODO(davidben): The FileSystemContext is NULL here. In the case where
    // another renderer requested this navigation, this should be the same
    // FileSystemContext passed into ShouldServiceRequest.

But I think we may continue to have cases where we don't supply one at all. This
FileSystemContext should be that of the renderer which /initiated/ the
navigation because any filesystem URLs (this isn't files on the user's
filesystem, but files in the HTML5 filesystem API) should be resolved relative
to the that renderer's FileSystemContext. If the browser's initiating a
navigation, I doubt it'd make much sense to require it make up a
FileSystemContext each time since the browser's probably never going to start
doing POSTs with a file upload of a filesystem URL. And if we're supporting
NULL, I figured it would be good to check this rather than pass NULLs around.

(On reflection, we want to find out if the browser ever tries to do this.
Switched it to a CHECK.)

+          element_readers.push_back(
+              new content::UploadFileSystemFileElementReader(
+                  file_system_context,
+                  element.filesystem_url(),
+                  element.offset(),
+                  element.length(),
+                  element.expected_modification_time()));
+        } else {
+          // If |body| contains any filesystem URLs, the caller should have
+          // supplied a FileSystemContext.
+          NOTREACHED();
+        }
         break;
       case ResourceRequestBody::Element::TYPE_BLOB:
         // Blob elements should be resolved beforehand.
         NOTREACHED();
         break;
       case ResourceRequestBody::Element::TYPE_UNKNOWN:
         NOTREACHED();
         break;
     }
   }
 
   return make_scoped_ptr(
       new net::UploadDataStream(element_readers.Pass(), body->identifier()));
 }
 
 }  // namespace content