Byte-range requests
farski opened this issue · comments
Apple requires (though I don't know about enforces) xml, images, and audio being hosted on servers with BRR support. This seems like a good thing to encourage generally, and having it as a standard also allows for some other useful techniques to be employed.
There are many situations where clients are currently assuming this is supported anyway. The thing that this makes more difficult is dynamic media, and I think that it may be worth specifying client behavior that makes it a little easier for dynamic media to work in combination with range requests. (e.g. ensuring that you cache redirects)
@farski Can you elaborate on "...other useful techniques"?
@chrisrhoden Can you elaborate on "...more difficult is dynamic media"?
@empaempa Essentially, if the media is being dynamically routed or generated, you need to ensure that all byte range requests from the same client are "routed" to the same logical media file to avoid problems where e.g. the media skips or chirps, or you jump between segments.
Let's imagine a situation where there are 2 versions of an audio file that are randomly assigned: one with a 5 second preroll, and one with a 30 second preroll. If the client and server do not coordinate to ensure that the same logical file (version) of the audio is always what is served to the client, you may wind up with a situation where, through range requests, the first half of the second file is downloaded and played, and the second half of the first file is downloaded and played. The impact on the user is that a ~ 25 second chunk of the audio in the middle will be missing.
It would be great to somehow be able to pin an id of some kind to the user to ensure that the same user always get served the same file. If the user gets a shorter file in the second range request the cdn will typically serve a 416 (invalid range request or something along those lines).