Range request and HTML5 Audio

Question

In the context of HTML5 audio, if the server is sent a request with the following header:

Range:bytes=0-

Will responding with

Content-Range: bytes 0-499/1234

Be handled correctly by all modern browsers? When byte[500] is needed, will the browser automatically know to request the next chunk? Am I interpreting the following spec correctly?

If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified range(s) are
valid and satisfiable (as defined in Section 2.1), the server SHOULD
send a 206 (Partial Content) response with a payload containing one
or more partial representations that correspond to the satisfiable
ranges requested, as defined in Section 4.

I've been reading from the following spec: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p5-range-22

Answer 1

If that request was generated internally by the browser by assigning the src attribute of an audio of video tag, then yes, the media element knows how to handle byte range requests and make subsequent requests for the next segments. No additional logic needed.

Answer 2

It sounds like you're interpreting the spec correctly. However, examples of ServiceWorkers responding to Range Requests suggests that the expected response to open-ended requests like 0- is the entire byte range. Browsers then stream the response up to some heuristic, and if the user seeks to a range outside of what has been streamed the initiate a subsequent open-ended request.

In order words, if there's a file with 1000 bytes: the first request is always Range: bytes=0-. The browser decides to load 100 bytes. The user seeks toward the end, and the browser sends another request Range: bytes=900-.

I've actually never seen instances where browsers request explicit, closed ranges like Range: bytes=0-100. They also don't seem to use the range size, i.e. 1234 in Content-Range: bytes 0-499/1234. I'm guessing this is because some servers may send * for files of unknown duration (or continuous, real-time playback).

Word of caution: this is based on my observations, predominantly of Firefox, Chrome, and iOS Safari. Behavior may vary based on browser vendor, version, etc.