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

  • I'd guess the range request is the browser trying to determine if the server supports range requests. – ceejayoz Feb 15 '16 at 1:44
  • @ceejayoz me too. I'd guess is a client bug? Anyway, interesting question – Fredi Feb 15 '16 at 1:47
  • This looks very much like what was described here 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 5: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

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.

  • 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 7:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.