Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Byte-range requests #38

Open
farski opened this issue Nov 5, 2016 · 6 comments
Open

Byte-range requests #38

farski opened this issue Nov 5, 2016 · 6 comments
Labels

Comments

@farski
Copy link
Member

farski commented Nov 5, 2016

No description provided.

@farski
Copy link
Member Author

farski commented Nov 5, 2016

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.

@farski farski added the idea label Nov 5, 2016
@farski farski added this to the January milestone Jan 3, 2017
@cqr
Copy link
Member

cqr commented Jan 3, 2017

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)

@empaempa
Copy link

empaempa commented Jan 9, 2017

@farski Can you elaborate on "...other useful techniques"?
@chrisrhoden Can you elaborate on "...more difficult is dynamic media"?

@cqr
Copy link
Member

cqr commented Jan 9, 2017

@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.

@farski
Copy link
Member Author

farski commented Jan 9, 2017

@empaempa I don't really know what I had in mind, something like #39 perhaps.

@markusahlstrand
Copy link

markusahlstrand commented Jan 9, 2017

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).

@farski farski removed this from the January milestone Mar 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants