Inconsistent support for Range header causes infinite download attempts
Reported by
shug...@anaconda.com,
Nov 6 2017
|
|||||
Issue descriptionUserAgent: 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
,
Nov 6 2017
Trying to fix this but - component isn't being displayed properly.
,
Nov 6 2017
,
Nov 7 2017
,
Mar 15 2018
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by mmenke@chromium.org
, Nov 6 2017