chrome.downloads.download requests with Range header set fails
Reported by
c...@nordenfelt.com,
May 13 2016
|
||||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36
Steps to reproduce the problem:
It's not really possible to reproduce this issue as it is a plugin used for a specific site which requires credentials. However, the "What went wrong" section describes the issue in detail.
What is the expected behavior?
Ranges of files should be downloaded from a CDN and saved on the local disk.
What went wrong?
We have a chrome extension that downloads files from a CDN.
The files on the CDN are BLOBs that consists of multiple files. n order to download the segements (chunks) of the BLOG that comprise the individual files we use the Range header:
var params = {
url: 'https://www.example.com/cdn/file.blob',
headers: [{ name: 'Range', value: 'bytes=0-200' }],
filepath: 'localfilename'
};
chrome.downloads.download(params, ...);
Running Chrome 49.0.2623 work perfectly but since Chrome 50.0.2661 it doesn't.
I have verified this by downgrading Chrome to 49.x and then updated again to 50.x.
The error we receive is from chrome.downloads.onChanged where all downloads that contain a Range header is immediately interrupted with an error saying SERVER_BAD_CONTENT which in turn ends up being a "No file" error in the download shelf. If I go in to the Download manager and click the URI of the failed downloads the file is downloaded as expected.
I also sniffed the failing requests using wireshark and recreated them in Postman. Each and every failed requests worked as expected when using Postman.
WebStore page: https://chrome.google.com/webstore/detail/tobii-cloud-downloader/pbhcdcnahkjmfmdobhlmblamoknmdccn
Did this work before? Yes Chrome 49.0.2623
Chrome version: 50.0.2661.102 Channel: stable
OS Version: OS X 10.11.2
Flash Version: Shockwave Flash 21.0 r0
,
May 16 2016
Thank you for providing more feedback. Adding requester "mgersh@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 16 2016
,
May 16 2016
Downloading a subrange of a resource is currently not supported. Internally Chrome/Chromium uses byte range requests for downloads resumption, and partial responses are interpreted to be responses for the partial requests constructed by the downloads system itself. Hence the unexpected 206 response code causes the logic to reject the response. We could consider adding support for downloading partial ranges using chrome.downloads.download. So I'll leave the bug as available and P-3, but I don't expect the functionality to be present by M-52.
,
May 17 2016
Hi, Has this been changed recently? Since it worked before Chrome 50 I would have to assume that Chrome 50 has somehow changed this implementation?
,
Mar 13 2017
Cleaning up "Needs-Review" label as we are not using this label for triage anymore. Ref bug for this cleanup 684919
,
Apr 13 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 19 2018
,
Apr 20 2018
benjhayden@chromium.org -> for downloads api triage
,
Apr 23 2018
For download triage please mark with component UI>Browser>Downloads and leave "Untriaged" and we'll triage it. This is lower priority but we'll get to it. benjhayden@ - Removing you to save you the noise but let me know if you actually want to be on this :).
,
May 3 2018
This might be breaking due to parallel downloads & resumption. We should be careful if the user is passing range headers as part of the download params. |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by mge...@chromium.org
, May 13 2016Labels: Needs-Feedback