0

I'm hosting a 2.9MB MP3 file with Nginx. When I navigate to its URL using Chrome on Android, there are two requests made: one normal request, and one two-byte range request.

When I copy the first request as a cURL command and execute it on Mac OS X, it downloads the file in its entirety. However, on Android only 3.7 KB are downloaded before the two-byte range request is fired off. Nginx obediently responds with only two bytes of data, and the audio controls displayed in Chrome are left non-functional.

I've tried setting max_ranges 0, disabling etags, gzip, etc. I can't seem to get Chrome to download the rest of the file.

First request:

GET /yt/test.mp3 HTTP/1.1 Host: xxx.xxx.xx.xxx Connection: keep-alive Pragma: no-cache Cache-Control: no-cache Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Linux; Android 6.0.1; Nexus 6P Build/MMB29Q) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.95 Mobile Safari/537.36 Accept-Encoding: gzip, deflate, sdch Accept-Language: en-US,en;q=0.8

Response:

HTTP/1.1 200 OK Server: nginx Date: Mon, 15 Feb 2016 01:12:31 GMT Content-Type: audio/mpeg Content-Length: 2891369 Last-Modified: Mon, 15 Feb 2016 00:26:18 GMT Connection: keep-alive ETag: "56c11b2a-2c1e69" X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Accept-Ranges: bytes

Second request:

GET /yt/test.mp3 HTTP/1.1 Host: xxx.xxx.xx.xxx Connection: keep-alive Pragma: no-cache Cache-Control: no-cache User-Agent: Mozilla/5.0 (Linux; Android 6.0.1; Nexus 6P Build/MMB29Q) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.95 Mobile Safari/537.36 Accept: */* Referer: https://xxx.xxx.xx.xxx/yt/test.mp3 Accept-Encoding: gzip, deflate, sdch Accept-Language: en-US,en;q=0.8 Range: bytes=0-1

Response:

HTTP/1.1 206 Partial Content Server: nginx Date: Mon, 15 Feb 2016 01:12:32 GMT Content-Type: audio/mpeg Content-Length: 2 Last-Modified: Mon, 15 Feb 2016 00:26:18 GMT Connection: keep-alive ETag: "56c11b2a-2c1e69" X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Content-Range: bytes 0-1/2891369

bluegate010
  • 99
  • 1
  • 4
  • I'd guess the range request is the browser trying to determine if the server supports range requests. – ceejayoz Feb 15 '16 at 01:44
  • @ceejayoz me too. I'd guess is a client bug? Anyway, interesting question – Fredi Feb 15 '16 at 01:47
  • This looks very much like what was described here http://stackoverflow.com/questions/3303029/http-range-header, I.e. it is indeed a means to detect if the server supports range requests. – Jeremy Gibbons Feb 15 '16 at 05:30
  • @JeremyGibbons I have seen that question as I was looking for a solution to this. It does look like a range-test request. Still confused, since on Mac OS X, Chrome's range request is "bytes 0-", and the entire file is retrieved. Only on Android am I seeing the "bytes 0-1" request. – bluegate010 Feb 15 '16 at 18:15

1 Answers1

1

Ok, pretty sure the issue is that Chrome offloads media fetching and playback to the Android MediaPlayer. In my situation, I didn't have my SSL certs set up correctly (since my domain name was temporarily erroneously blacklisted by my registry). I could manually click through the security warnings in Chrome to get to the page, but I think as soon as MediaPlayer tried to take over fetching the resource, it gave up over the certificate error.

Not 100% sure this was the issue, but my domain is back in service and things are working now. I probably could have saved myself some headache by disabling HTTPS back when I was working with raw IP addresses.

bluegate010
  • 99
  • 1
  • 4
  • I just had a similar issue with self-signed certificates. After reading your answer, I tried in HTTP, I was able to play sounds, and no more 0-1 range requests. – Volune Jul 20 '16 at 07:20