fix: handling range headers correctly when full content requested

[alexmaras]

This addresses #68

The issue occurred because I didn't implement the full set of Range/Content-Range header requirements.
The setup now handles ranges that have no end byte provided (i.e. Range: bytes=0-) which by the spec return the full length of the content starting from the starting byte.

Just also testing at the moment that Clipious in Dash mode continues to work.

[Fijxu]

Works fine. Thanks! I can also seek into unbuffered parts of a video without problems which was something that I couldn't do before because it would throw me "The media playback was aborted due to a corruption problem or because the media used features your browser did not support." if I tried to seek into an unbuffered part of the video.

[alexmaras]

Thanks, good to hear 👍 I'm going to make sure this still works with Clipious before getting @unixfox to review

[alexmaras]

OK, seems to work well with Clipious too. Open for review.

[unixfox]

Thanks alex. But did you guys check out how invidious videoplayback code works: https://github.com/iv-org/invidious/blob/master/src/invidious/routes/video_playback.cr?

For example, if the range header is not present then it requests a fixed range: https://github.com/iv-org/invidious/blob/master/src/invidious/routes/video_playback.cr#L39-L43

There is also the fact that some videoplayback proxy handle the query string "range" too: https://github.com/TeamPiped/piped-proxy/blob/main/src/main.rs#L310-L336. I'm planning on switching to a range query string for the video.js player: iv-org/invidious#5087

[alexmaras]

I'm happy to look into more range header/query param handling, but I'd prefer to do it in a follow-up PR as this is fixing a bug with the existing player. If I add more checks in, I want to be able to test them out, and it'll be easier to do that in isolation after that's fixed.

If we don't have one already, putting an issue in for those 2 improvements would be great, so it doesn't get forgotten.