It seems like we depend on an Etag or Last-Modified to be present before we allow downloads to resume. However, downloads happily resume if the ETag/Last-Modified/Content-Length has changed between chunks, despite these being strong indications that the content has changed, and the previously fetched chunks may be invalid.

This could leave the user with a file that's corrupt, which could (if the user is unluck enough) do some damage.

Test: https://github.com/jakearchibald/range-request-test (sorry, I tried to externally host it, but fontend servers kept messing with the behaviour)

You'll need a recent version of node. I'm using 8.0.0. Once the project is checked out, run:

npm install 
npm run serve

Then visit http://localhost:3000.

In the Test Download section, select:

* 100 MB
* Accept range
* Include ETag (and/or Last-Modified)
* CHEESE

Click "Download".

After a few seconds, pause the download.

Press "Close last download connection" (since Chrome holds onto the connection by default).

Select "petril" - this changes the content downloaded, along with the ETag & Last-Modified headers.

Resume the download. Chrome will send a range request for the rest of the resource, and ignore the header changes.