Parallel download should handle Content-Range header for download resumption. |
||||
Issue descriptionVersion 62.0.3197.0 (Developer Build) (64-bit) Linux How to repo: 1. Download with parallel download, wait for about 8 seconds for history db to persist parallel download data. 2. Restart chrome. 3. Resume the download from chrome://download 4. Hit a DCHECK. or download will not complete. Reason: Download resumption with download slices will result in sending range request on download resumption. We also check Accept-Range header to create ParallelDownloadJob to do actual work. But according to RFC7233, 206 partial content will response with Content-Range instead of Accept-Range, so the resumption request will be single request. However, since it has slices info, in DownloadFileImpl, we will stop the request in the middle, because we assume there can be another request filling the other hole, thus cause the download unable to complete.
,
Aug 26 2017
,
Aug 26 2017
,
Aug 27 2017
I think Accept-Range in 206 response is optional, some server did send Accept-Range. Like this one: xingliu@xingliu0:/usr/local/google/code/clankium/src$ curl -I --header "Range: bytes=10-20" http://eclipse.mirror.rafal.ca/technology/epp/downloads/release/oxygen/R/eclipse-jee-oxygen-R-linux-gtk.tar.gz HTTP/1.1 206 Partial Content Date: Sun, 27 Aug 2017 01:26:19 GMT Server: Apache/2.4.10 (Debian) Last-Modified: Sun, 25 Jun 2017 10:00:00 GMT ETag: "14475070-552c5e5bda800" Accept-Ranges: bytes Content-Length: 11 Content-Range: bytes 10-20/340217968 Content-Type: application/x-gzip
,
Aug 28 2017
Site to repro: https://www.thinkbroadband.com/download Use large files or very large files to verify this issue.
,
Aug 29 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/adf37191953b687857d1224890ffa8148174e974 commit adf37191953b687857d1224890ffa8148174e974 Author: Xing Liu <xingliu@chromium.org> Date: Tue Aug 29 19:36:15 2017 Fixed parallel download resumption issue. Some servers don't include Accept-Range header in HTTP 206 response. So resumption download may be normal download but with received slices, which will block the download to be completed. This CL fixed this issue and make sure received slices are properly cleared when resume with a normal download. A browser test is implemented for this case, and fixed the test harness that it used to always include Accept-Range header in 206 response. Bug: 759263 Change-Id: I381949318cac375a7cb01278f855781c30e485f5 Reviewed-on: https://chromium-review.googlesource.com/639392 Reviewed-by: David Trainor <dtrainor@chromium.org> Reviewed-by: Alex Moshchuk <alexmos@chromium.org> Reviewed-by: Min Qin <qinmin@chromium.org> Commit-Queue: Xing Liu <xingliu@chromium.org> Cr-Commit-Position: refs/heads/master@{#498201} [modify] https://crrev.com/adf37191953b687857d1224890ffa8148174e974/content/browser/download/download_browsertest.cc [modify] https://crrev.com/adf37191953b687857d1224890ffa8148174e974/content/browser/download/download_create_info.h [modify] https://crrev.com/adf37191953b687857d1224890ffa8148174e974/content/browser/download/download_item_impl.cc [modify] https://crrev.com/adf37191953b687857d1224890ffa8148174e974/content/browser/download/download_job_factory.cc [modify] https://crrev.com/adf37191953b687857d1224890ffa8148174e974/content/browser/download/download_request_core.cc [modify] https://crrev.com/adf37191953b687857d1224890ffa8148174e974/content/browser/download/parallel_download_job.cc [modify] https://crrev.com/adf37191953b687857d1224890ffa8148174e974/content/browser/download/parallel_download_job_unittest.cc [modify] https://crrev.com/adf37191953b687857d1224890ffa8148174e974/content/public/test/test_download_request_handler.cc [modify] https://crrev.com/adf37191953b687857d1224890ffa8148174e974/content/public/test/test_download_request_handler.h
,
Aug 30 2017
,
Aug 31 2017
|
||||
►
Sign in to add a comment |
||||
Comment 1 by xingliu@chromium.org
, Aug 26 2017Labels: -Pri-3 M-62 OS-Android Pri-1
Status: Assigned (was: Untriaged)