[Downloads] Always call DM::StartDownload() for explicit downloads.
Every explicitly initiated download should be represented in the UI with
the exception of downloads which are hidden or downloads which were
cancelled by the user or were blocked by a throttle. This is currently
not true for downloads whose requests fail before a response is
available (e.g. because of the hostname not being resolved) because the
DownloadManager is only notified during
DownloadResourceHandler::OnResponseStarted(). Failure to notify the
DownloadManager results in no DownloadItem being created, and
subsequently no UI being presented to the user.
The current behavior is also non-ideal for downloads resumption. When a
partial download request receives a HTTP 412 response, the current logic
invokes DownloadManager::StartDownload() with no indication that the
Content-* headers received do not apply to the desired entity. Therefore
the DownloadItem's ETag and Last-Modified headers can be incorrectly
reset after a pre-condition failure.
This CL makes the following changes:
- DownloadItem::Start() now consumes a DownloadCreateInfo since multiple
requests can be associated with a single DownloadItem due to
resumption. Each new request results in a Start() call.
- DownloadResourceHandler invokes DownloadManager::StartDownload() even
when no OnResponseStarted is received. The only exception is if the
associated renderer goes away between the time the download request is
sent and the time the response is received.
- UrlDownloader always invokes DownloadManager::StartDownload() for all
initiated download requests without exception.
- DownloadItemImpl invokes the delegate and requests a filename whenever
one is needed.
- DownloadTargetDeterminer generates a valid filename even if the
DownloadItem is not in-progress.
- DownloadUrlParameters::OnStartedCallback could now receive a valid
DownloadItem even when the request fails.
- ResourceDispatcherHost::BeginDownload() is no longer a public API. All
wannabe downloaders must now go through DownloadManager to initiate a
download.
- ResourceDispatcherHostImpl is no longer responsible for invoking
OnStartedCallback or pass through download parameters.
DownloadRequestCore attaches the data direcly to explicit downloads.
Ideally, explicit download initiation would first start by creating a
DownloadItem. We aren't quite there yet due to the fact that consumers
of the download system make assumptions about the existence of a
download item. I.e. the fallacy that the existence of a download item
must mean that that download is a candidate to be presented to the UI or
other consumers. Once these consumers are fixed, then we can move all
explicit download request initiated into DownloadItem, thus simplifying
much of this logic.
BUG=7648
Review URL: https://codereview.chromium.org/148133007
Cr-Commit-Position: refs/heads/master@{#376487}
37 files changed
