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

Steps to reproduce the problem:
1. Make lots of binary XMLHttpRequests to different files with valid range-request headers. In my case the first 4096 bytes of a file. Try throwing in some out-of-range requests and ignoring the result – I think this may be the trigger.
2. Reload the page and perform the same requests
3. Check the responses for valid data
4. Notice that if Chrome uses the disk cache to handle the response, there's a small chance the returned arraybuffer will be all zeros. After this has happened, Chrome always return zeros until the cache is cleared

In my app I can trigger the issue fairly reliably – once every few attempts. I think the key to trigger it is invalid requests happening around the same time

What is the expected behavior?
When performing a http range request it should always return the expected bytes, whether from the remote source or from local disk cache

What went wrong?
When performing a binary XMLHttpRequests with range-request headers, occasionally the returned arraybuffer is all zeros but the correct length. This only happens when chrome uses the disk cache to handle the request and does not happen in other browsers or using other servers. (Chrome reports "(from disk cache)"  in dev tools for the request. I think it's triggered by invalid range requests happening around the same time as the valid request

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 66.0.3359.181  Channel: n/a
OS Version: OS X 10.13.4
Flash Version: 

If I download the complete file from dev-tools, the first 4096 bytes is zeroed out, so I'm confident that the bad data is _within_ chrome's cache and not an application-level issue. I've tried different servers to handle the range requests and found the same results. This doesn't rule out a server issue but makes it less likely

Safari also caches range requests but I cannot reproduce