content
content copied to clipboard
mdn
HTTP Range Request: Requesting a range of bytes (such as of a video file)
MDN URL
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Ranges
What specific section or headline is this issue about?
(entire article)
What information was incorrect, unhelpful, or incomplete?
This information is clear and well-written, but It only describes the Accept-Ranges header itself, saying that it advertises acceptance of range requests, but doesn't seem to have a link to a description of how the browser actually requests a range of bytes to be delivered. Don't you agree that there should be a paragraph of information about this, or a link to the information?
What did you expect to see?
Wanted a top-level description of the whole process of returning a video file to a request, including how the default browser video player requests a byte range and how the application should satisfy that request. I'm having difficulty finding this information on the Web because I don't know exactly what terms to search for.
Do you have any supporting links, references, or citations?
See Also:
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests
- https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range
Do you have anything more you want to share?
No response
MDN metadata
Page report details
- Folder:
en-us/web/http/headers/accept-ranges - MDN URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Ranges
- GitHub URL: https://github.com/mdn/content/blob/main/files/en-us/web/http/headers/accept-ranges/index.md
- Last commit: https://github.com/mdn/content/commit/4fcc63ff26c0cf5dcbf4ee17091db727bdbba1a6
- Document last modified: 2022-06-11T04:19:10.000Z
I think a related page is https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests . There is no link to that page. I haven't yet found an overview page explaining the whole process of sending a MIME file.
I have achieved success in displaying a video stream to the user, including handling range requests. Wow. Some interesting complications are involved. I could write a description of what is needed, or provide my code, but I don't think I can write an MDN page using correct formatting. Either someone could work with me on this task, or I'll just abandon it. The thing is, that properly documenting how to serve a MIME file would be a good thing for MDN to have; it would have saved me a couple of days of work experimenting to determine exactly what happens.
@David263 Could this go in a guide topic? Then the formatting is is then not so important as telling a good story, and you could instead link to/from the references.
@teoli2003 I know little about this topic, is it something you could comment on?
Good. Please give me a link to the tutorial for creating a Guide Topic, and I'll do it.
Hi @David263.
The guide instructions can only be described as "rudimentary": https://developer.mozilla.org/en-US/docs/MDN/Structures/Page_types#conceptual_page
Essentially they say "copy the pattern of some other guide page that does similar things". We're fairly free-form on the structure, though I'd say "use lots of headings and examples".
One significant question that arises when considering the range request mechanism is how the server is expected to know what file is being served. The writeups all mention just one HTTP header: range, which specifies what byte ranges the server should provide, but it fails to specify the pathname of the file. The reason this is needed is that the user may be looking at an array of video players, and randomly repositioning several videos asynchronously. If the server really doesn't have the pathname in the request, pieces of incorrect files could be returned to the players, causing them to malfunction. I haven't found this issue discussed on the Web as yet.
I would like to write a guide for HTTP range request. I don't have any prior knowledge about this topic. But, I can research about this topic and try to deliver the best I can. I would be happy to take the help of @David263 & @hamishwillee, if I am stuck somewhere. Could you please assign it to me, @sideshowbarker ?
One significant question that arises when considering the range request mechanism is how the server is expected to know what file is being served. The writeups all mention just one HTTP header: range, which specifies what byte ranges the server should provide, but it fails to specify the pathname of the file. The reason this is needed is that the user may be looking at an array of video players, and randomly repositioning several videos asynchronously. If the server really doesn't have the pathname in the request, pieces of incorrect files could be returned to the players, causing them to malfunction. I haven't found this issue discussed on the Web as yet.
@David263 , the byte range of any file that we are requesting the server is sent as a property in the request header along with the url(pathname) of that image. This is how the server knows which file to serve.
Eventhough, if you are running 4 different video players asynchronously(let us assume that you have youtube open in 4 tabs where you playing 4 different videos), then the request sent from each video player is different and each request has the url of the video and the requested byte range.
@David263 Could this go in a guide topic? Then the formatting is is then not so important as telling a good story, and you could instead link to/from the references.
@hamishwillee , I am currently assigned the task to write the guide for HTTP range requests. Then I realised that there is already a very good explanation for HTTP range requests in the reference section of MDN docs and the link to it is here. I think that this topic doesn't need a separate guide as it is already so good.
If you still think that this needs a guide, kindly share more details on why you think that this section would need a separate guide. Also, under which section of the guides do you think that this item could go?
The simple answer is that MDN doesn't explain what media players actually do to interact with the server in serving a large media file.
There are many possible interactions permitted by the design, but few are actually used, those that are used are different between different browsers and operating systems (MacOS/Safari is an oddball) and there are significant pitfalls in programming for this design. It is very easy to have bugs with the current partial documentation.
What is needed is a description of the specific handshaking that goes on, and information about how to maintain the state information throughout the serving process, given that there is no explicit state information, such as the file path, available during the transfer.
The current documentation is accurate, as far as my experimentation has shown. But it doesn't go deep enough to provide the help that MDN documentation provides in so much other Web programming.
@David263, You are saying that it would be a good thing to have a guide on how media players interact with Web servers to stream the content to the user. From my research, I was able to find out that HTTP range request is only a concept that is helpful for streaming video content and it is not everything in video streaming. I don't think that HTTP range requests section of the documentation is the appropriate place to accommodate a guide on 'how streaming services work?'.
If you agree with my thoughts, could you suggest to me which part of the documentation is the right place to hold the content that you are asking for? Thank you!
You seem to be getting a bit theoretical. That is fine, and I will respond to your thoughtful comment in kind, as software theory is one of my interests.
I'm afraid I can't agree with you. Most major aspects of Web programming are covered in MDN currently, which makes it the best single source of Web programming information. I can't agree that good and relevant information should be omitted from it, if this is indeed what you are suggesting.
While I'm relatively new to MDN, my understanding is that its content is presented in two ways: in guides that describe how a particular aspect of Web programming is done, and in specific pages for each specific syntactic Web programming construct. About the only thing missing are fundamental tutorials on elementary topics; these are left to other sources. This is just fine; MDN doesn't have to be all things to all people.
While "everything" about a topic is too much to be expected due to the complexity of all of Web programming (although the success of Wikipedia shows that it is possible to address such a goal), MDN already provides basic guides to most aspects of Web programming, so I haven't asked for any new direction for MDN, just for this topic, large file streaming, to be covered.
Streaming is mostly done by two HTTP headers, so it's not a particularly complex topic. What makes it difficult for programmers (I've given the specifics in my previous comments) is the lack of a guide in MDN. Just as with other such topics, experts in the field can provide guides effortlessly, since they know the topics inside out. Others can also write guides, at the cost of some research and experimentation.
The basic problem, theoretically, is that the current art of programming does not by default include priorities for such aspects as debugging and documentation, so documentation (in particular) has to be added at a later time by other than the original designers of Web programming features.
In the early days of computer science curricula, teachers such as Donald Knuth emphasized that early debugging and documentation were key to software quality. He showed that they had the potential to make software development more cost-effective and responsive to its users, thus fulfilling its promise of making computers really useful to all.
Today, software development is not much influenced by such academic considerations. It is guided mostly by very bright individuals who see what is needed and make it happen, sometimes in the context of standards committees, sometimes not. The actual work is done through Open Source and proprietary organizations.
All of this is fine, and I am not asking for a return to evidence-based academics. All I ask for is a conscious recognition by those associated with excellent projects such as MDN that debugging and documentation are essential to good user and customer experiences.