Accept Ranges: bytes
See original GitHub issueHow easy would it be to add support for video range requests? If it’s non-trivial then not to worry, thought I’d ask.
I am writing something that plays videos in HTML5 and noticed that url#t=[start_time][,end_time]
wasn’t working, and then realised that sirv didn’t have Accept Ranges: bytes
for the video content request although it was serving the file ok. Would be nice to have the feature but if it’s not within the scope of this project then fair enough. Thank you.
Issue Analytics
- State:
- Created 4 years ago
- Comments:8 (4 by maintainers)
Top Results From Across the Web
Accept-Ranges - HTTP - MDN Web Docs
The Accept-Ranges HTTP response header is a marker used by the server to advertise its support for partial requests from the client for...
Read more >HTTP headers | Accept-Ranges - GeeksforGeeks
bytes : This directive defines the unit of range which is bytes. You can request byte ranges. None: It means no range unit...
Read more >What are HTTP Byte Range Requests and how do they help?
Byte range requests are a feature of HTTP that allows you to request only a portion of a resource. They help with smooth...
Read more >Byte serving - Wikipedia
Byte serving begins when an HTTP server advertises its willingness to serve partial requests using the Accept-Ranges response header. A client then requests ......
Read more >Byte-Range Requests - KeyCDN Support
In order to initiate a byte range request the client will use the range request header to specify what byte range it is...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Ok so here’s a summary: servers and browsers aren’t required to do anything with range requests, but when they do then either side can do something about it.
So due to this policy when requesting a video directly in the browser window one can expect inconsistent results.
However range requests should work as expected in a typical use case, for example when embedding a video in an HTML Video element . I’ve tested Sirv with Chrome and Firefox and in both cases everything works as expected. I’m happy to leave it there.
Here’s the RFC for reference;
In other words, despite the
Accept-Ranges
header isn’t required before sending data, in some cases the browser may understand that the web server doesn’t support ranges when this header isn’t present.For this issue, Firefox may be understanding that Sirv doesn’t support ranges on direct access, because it isn’t even trying to test a range request.
To solve this, I believe that sirv would have to always send the
Accept-Ranges
header on the first response to ensure to the browser that it supports it, but this could potentially reduce the overall performance of Sirv.