Browser audio-playback fails when Accept-Ranges not set in http headers; WHY?

Question

I recently discovered something (that surprises me) when opening an audio file in firefox or chrome. If I don't specify the HTTP response header "Accept-Ranges: bytes", firefox won't be able to determine the length of the ogg file (in seconds) before reaching the end in playback. Chrome will discover the length of the ogg file (in seconds), but the audio player appears to crash when it reaches the end, and refuses to re-play the file after the crash. Other browsers were not tested.

Working Http response headers:

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: application/ogg
Content-Length: 245646

Failing Http response headers:

HTTP/1.1 200 OK
Content-Type: application/ogg
Content-Length: 245646

This is strange to me, because I'm not using any partial-content ranges. My server implementation doesn't even support them (so I think my server might be lying when it says "Accept-Ranges: bytes"). I certainly don't see why this header should be required for playback within the browser. Do both browsers just have bugs, which are exposed when I don't set the Accept-Ranges header? This seems unlikely to me. Can anyone explain?

Thanks!

Answer 1

Not sure this is a bug or just a skewed interpretation of the standard - section 14.5 . The standard states MAY and not MUST...

OTOH it can be that for being able to use an audio-stream and/or seeking etc. the implemented audio playback modules need this header... you can try out what happens if you submit "Accept-Ranges: none"... if they are a bit http 1.1 conforming than it just works...