Introduce ParallelDownloadJob.

content/browser/download/download_job_factory.cc

Index: content/browser/download/download_job_factory.cc
diff --git a/content/browser/download/download_job_factory.cc b/content/browser/download/download_job_factory.cc
new file mode 100644
index 0000000000000000000000000000000000000000..f87a3f89a989b619fddf3905d8b455845a009a61
--- /dev/null
+++ b/content/browser/download/download_job_factory.cc
@@ -0,0 +1,53 @@
+// Copyright 2017 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/download/download_job_factory.h"
+
+#include <memory>
+
+#include "base/memory/ptr_util.h"
+#include "content/browser/download/download_item_impl.h"
+#include "content/browser/download/download_job.h"
+#include "content/browser/download/download_url_job.h"
+#include "content/browser/download/parallel_download_job.h"
+#include "content/public/common/content_features.h"
+
+namespace content {
+
+namespace {
+
+bool ShouldUseParallelDownload(const DownloadCreateInfo& create_info) {
+  // TODO(xingliu): We should follow RFC 7232 section 2 on strong validators.
+  // Parallel download requires:
+  // 1. Accept-Ranges, Content-Length and strong validators response headers.
+  // 2. Feature |kParallelDownloading| enabled.
+  // 3. (Undetermined) Http/1.1 protocol.
+  // 4. (Undetermined) Not under http proxy, e.g. data saver.
+  bool has_strong_validator =

[asanka, 2017/02/16 16:27:39]

Not the place to determine this.

See
https://cs.chromium.org/chromium/src/net/http/http_response_headers.cc?rcl=7b...

DownloadRequestCore has access to this information, and consequently etag and
last_modified would only be non-empty if they are considered strong validators
:-). There would be no point in keeping those around if they weren't.

Another option is to also check for Accept-Ranges and only store validators if
they could be used for range requests. Once again, there's no point in keeping
validators around for downloads if they couldn't be used for range requests.

[xingliu, 2017/02/20 18:59:11]

Oh, I see. Thanks.

+      !create_info.etag.empty() || !create_info.last_modified.empty();
+
+  return has_strong_validator && create_info.accept_range &&
+         create_info.total_bytes > 0 &&
+         base::FeatureList::IsEnabled(features::kParallelDownloading);
+}
+
+}  // namespace
+
+std::unique_ptr<DownloadJob> DownloadJobFactory::CreateJob(
+    std::unique_ptr<DownloadRequestHandleInterface> req_handle,
+    const DownloadCreateInfo& create_info) {
+  std::unique_ptr<DownloadJob> job;
+
+  // Build parallel download job.
+  if (ShouldUseParallelDownload(create_info)) {
+    job = base::MakeUnique<ParallelDownloadJob>(std::move(req_handle));

[asanka, 2017/02/16 16:27:39]

return base::MakeUnique<...>(...)

No need to store it in job.

[xingliu, 2017/02/20 18:59:11]

Done.

+    return job;
+  }
+
+  // An ordinary download job.
+  job = base::MakeUnique<DownloadUrlJob>(std::move(req_handle));

[asanka, 2017/02/16 16:27:39]

Let's rename DownloadUrlJob to something else so that the distinction between
ParallelDownloadJob and DownloadUrlJob is clear.

[xingliu, 2017/02/20 18:59:11]

Done. Renamed to DownloadJobImpl.

+  return job;
+}
+
+}  // namespace