User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11 Steps to reproduce: Trying to fetch a HTML5 video from a server. Actual results: GET /w HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.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 Connection: keep-alive Range: bytes=0- Referer: http://localhost/ HTTP/1.1 206 Partial Content Accept-Ranges: bytes Content-Length: 1048576 Content-Range: bytes 0-1048575/5071076 Content-Type: video/webm When playing video using the default controls, firefox doesn't try to fetch the rest of the data. Seeking doesn't seem to be working in this scenario either. Expected results: Here's what happens on chromium: GET /w HTTP/1.1 Host: localhost Connection: keep-alive Accept-Encoding: identity;q=1, *;q=0 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11 Accept: */* Referer: http://localhost/ Accept-Language: en-US,en;q=0.8 Accept-Charset: UTF-8,*;q=0.5 Range: bytes=0- HTTP/1.1 206 Partial Content Accept-Ranges: bytes Content-Length: 1048576 Content-Range: bytes 0-1048575/5071076 Content-Type: video/webm GET /w HTTP/1.1 Host: localhost Connection: keep-alive Accept-Encoding: identity;q=1, *;q=0 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11 Accept: */* Referer: http://localhost/ Accept-Language: en-US,en;q=0.8 Accept-Charset: UTF-8,*;q=0.5 Range: bytes=1048576- HTTP/1.1 206 Partial Content Accept-Ranges: bytes Content-Length: 1048576 Content-Range: bytes 1048576-2097151/5071076 Content-Type: video/webm (...) And so on. Chromium keeps asking for additional chunks of data. So does safari. Firefox doesn't do anything even though the resource is clearly available on the server.

Does it work on a Nightly Build? http://nightly.mozilla.org/

Nightly behaves the same way.

Did you specify the "preload" attribute on your <video> element? Without this Firefox will stop the download after downloading the first frame. i.e.: <video src="http://...." preload></video>

Looks like attempting to preload the video makes no difference. Firefox expects the whole file after requesting Range: bytes=0-. When the webserver refuses to just stream the whole thing and instead sends a single chunk, firefox draws a blank. Other browsers try to actively fetch the missing data. To be honest, responding to Range: bytes=0- with only a part of requested resource is an error on part of the server, but chromium and safari at least seem not to mind.

Ah, so you're saying that Firefox requests "bytes=0-", but the server only returns "bytes=0-n", and Firefox doesn't trigger another request for "bytes=n-".

This sounds like a dupe of bug 570755.

Indeed it does. Thanks for filing softcushiontorture, please reopen this bug if this doesn't look like a duplicate of bug 570755.

Just to follow up on bug 570755, I no longer work for the company I was working for when I was interested in getting Firefox to stream the video in the way Chrome did. I didn't get the right traffic from the standards bodies either. Another method I attempted (using node.js) was to let the browser make the full request (0-) and attempt to deliver it. Instead of ending the request abruptly on the server I paused the server response (and the the client video controls) and then waited for heart-beat from the client to unpause the server. I worried that this would eventually lead to a timeout or a retry (or reseek/rebuffer) by the client so I didn't pursue it too far. Another concern was that I would have lots of open network sockets instead of being able to close them while waiting for the client to come back for more. HLS seems to be the best modern approach.