问题
To give some context, I have a <video> tag that has a src attribute that points to a method on my node.js server. That method gets an mp4 file from another server, or rather part of an mp4 file, depending on the Range HTTP header specified by the browser, for example - Range:bytes=0-.
Expected Behaviour (Chrome behaviour)
To prevent my node.js server from downloading the entire file from the third party server, I have implemented a max buffer of around 5MB to download at one time. So if the the user sends a request with to fetch the video with the headers
GET /play-test/videoId HTTP/1.1
Host: 127.0.0.1:8000
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Accept-Encoding: identity;q=1, *;q=0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
Accept: */*
Referer: http://127.0.0.1:8000/movie/99861
Accept-Language: en-US,en;q=0.8,es;q=0.6
Range: bytes=0-
..then my server will respond with
HTTP/1.1 206 Partial Content
X-Powered-By: Express
Content-Range: bytes 0-5000000/415473786
Connection: keep-alive
Accept-Ranges: bytes
Content-Length: 5000001
Content-Type: video/mp4
Date: Tue, 20 Oct 2015 12:50:42 GMT
This, I believe, is a common enough pattern - although the client (in this case, the browser) has requested has requested bytes=0- (start to end), I have instead responded with the first 5MB and most importantly told the client that response contains only those 5MB out of a total of 415MB (Content-Range: bytes 0-5000000/415473786). The response is also has a status of 206 indicating that the response is a partial one.
In Chrome, this works as expected - just before the video has finished playing the first 5MB of video it makes another request to the same endpoint but with the headers
GET /play-test/videoId HTTP/1.1
Host: 127.0.0.1:8000
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Accept-Encoding: identity;q=1, *;q=0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.101 Safari/537.36
Accept: */*
Referer: http://127.0.0.1:8000/movie/99861
Accept-Language: en-US,en;q=0.8,es;q=0.6
Range: bytes=5000001-
Again I respond with the maximum 5MB...
HTTP/1.1 206 Partial Content
X-Powered-By: Express
Content-Range: bytes 5000001-10000001/415473786
Connection: keep-alive
Accept-Ranges: bytes
Content-Length: 5000001
Content-Type: video/mp4
Date: Tue, 20 Oct 2015 12:51:08 GMT
This pattern continues until the video ends, the user pauses or skips using the seek bar, in which case the browser request a specific byte range for the time required. As I said, all works well in Chrome.
Firefox behaviour
Describing Firefox's behaviour is much more straight-forward that describing the correct behaviour!
Firefox request
Host: 127.0.0.1:8000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:41.0) Gecko/20100101 Firefox/41.0
Accept: video/webm,video/ogg,video/*;q=0.9,application/ogg;q=0.7,audio/*;q=0.6,*/*;q=0.5
Accept-Language: en-US,en;q=0.5
Range: bytes=0-
Referer: http://127.0.0.1:8000/movie/272
Connection: keep-alive
Response
206 Partial Content
Accept-Ranges: bytes
Connection: keep-alive
Content-Length: 5000001
Content-Range: bytes 0-5000000/415473786
Content-Type: video/mp4
Date: Tue, 20 Oct 2015 13:15:49 GMT
X-Powered-By: Express
Then that's it - Firefox plays the first 5MB of video and the no further requests are made to the server. The seek bar displays the correct duration of the video but the seek bar is non-functional. When the user attempts to seek the video skips back to the beginning and plays the first 5MB again.
Any help would be appreciated.
回答1:
the client (in this case, the browser) has requested has requested bytes=0- (start to end), I have instead responded with the first 5MB
I think that's your problem right there. The spec says that you should return the entire available byte range when a client ask for a range of 0-. You're not following the spec, hence why it doesn't work.
来源：https://stackoverflow.com/questions/33237902/firefox-wont-request-further-data-after-receiving-206-with-specified-content-ra