When Chrome is downloading from a webserver, and the webserver sends the "Accept-Ranges: none" header, Chrome ignores the header and still sends range requests.

This bug was found while investigating https://bugs.chromium.org/p/chromium/issues/detail?id=817848.

We'll use a similar repo process to what is used in the aforementioned bug. We'll use netcat (nc) to act as a webserver and have Chrome (65.0.3325.146) download from it.

First, we'll use the file 'resp' to serve content from nc. A copy of 'resp' is attached. It's headers look like:

$ head -7 resp
HTTP/1.1 200 OK
Content-Type: application/binary
Content-Encoding: gzip
Content-Length: 297
Accept-Ranges: none
ETag: foo


Then we can start netcat listening on port 8080 and serving 'resp'. And we can see the request received from Chrome when we navigate to http://localhost:8080/foobar.

$ nc -l 8080 < resp
GET /foobar HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.146 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9

^C

The download will not complete because the content in 'resp' is not complete. So it is as if the webserver terminates the connection. Then to see the resume request, restart nc listening on port 8080 and then manually resume the download in Chrome.

$ nc -l 8080
GET /foobar HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Range: bytes=368-
If-Range: foo
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.146 Safari/537.36
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9

^C

As we can see from that request, Chrome is still sending a range request, even though the webserver specified "Accept-Ranges: none".



 

Deleted: resp 374 bytes

resp 374 bytes View Download