New issue
Advanced search Search tips

Issue 781896 link

Starred by 1 user

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Inconsistent support for Range header causes infinite download attempts

Reported by shug...@anaconda.com, Nov 6 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.75 Safari/537.36

Example URL:
Non

Steps to reproduce the problem:
Note I cannot reproduce this in chrome itself, this is based on painstakingly picking apart our server side logging of HTTP requests.
We noticed this after a single user managed to download 15TB in a few hours trying to download one file.
1. Initial HTTP2.0 streaming request fails (because of a connection hiccup?)
2. Chrome attempts to download the entire file using HTTP1.0 and 'range' header with 'bytes=0-', this I guess fails too. 
3. CloudFlare is responding to these requests with a 206 status, indicating it does support range requests. 
3. Chrome then starts request ranges of bytes like bytes=401057050-534742735'
4.  A few moments later CloudFlare manages to cache the file, then it begins to respond with HTTP 200 statuses, which should indicate to the browser it does NOT support partial range requests
5. Chrome ignores this and continuously submits requests for partial ranges for many hours or until the user stops the download.

We have noticed this multiple times and the user agent string is 'Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36' indicating a chrome browser.

CloudFlare and our origin server do appear to not be behaving as one might expect, and I believe that is what is causing this Chrome bug. 

What is the expected behavior?
Chrome should deal with the sudden lack of support for partial range requests gracefully and either terminate the download or fall back to trying to download the entire file.

What went wrong?
Chrome browser is using terabytes of bandwidth when this bug occurs at locations with high bandwidth capabilities. This is not good for the user or servers.

Did this work before? No 

Chrome version: 61.0.3163.100  Channel: stable
OS Version: 
Flash Version: 

We first started to notice this around the time Chrome begin to support parallel downloads via partial range requests but were not able to track it down till recently.
I've attached a CSV of some of what we see in our logs. If you want more details or more examples I can hunt some down.
 The relevant ticket for parallel download implementation is here.
https://bugs.chromium.org/p/chromium/issues/detail?id=644352&q=partial%20range%20download&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified
 
problem.csv
11.4 KB View Download
Components: -Internals>Network Internals>Network>Cache
Components: -Internals>Network>Cache Internals>Network
Trying to fix this but - component isn't being displayed properly.
Components: -Internals>Network Internals>Network>Cache
Status: Untriaged (was: Unconfirmed)
Cc: morlovich@chromium.org

Sign in to add a comment