Support HTTP range requests #18

New issue

Open

opened 2023-11-16 18:12:28 +01:00 by Jef Roosens · 1 comment

Jef Roosens commented

2023-11-16 18:12:28 +01:00

Owner

For hosted files, HTTP range requests would be useful as they allow users to resume a download. I do think this will require some refactoring of the HTTP library though, so this might be a bit of a challenge to implement.

For hosted files, [HTTP range requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests) would be useful as they allow users to resume a download. I do think this will require some refactoring of the HTTP library though, so this might be a bit of a challenge to implement.

Jef Roosens added the

Kind/Feature

label 2023-11-16 18:12:28 +01:00

Jef Roosens commented

2023-11-19 10:03:59 +01:00

Author

Owner

I just had a thought on how this could be implemented.

The concept of response steps was introduced to allow custom code to write the response body, e.g. streaming the data from a store entry. However, this might be the wrong way to solve this.

Instead, we could introduce a "data reader" function that can be configured for each route. The signature of this function would include a buffer to write to, an index inside the response body from which to read, and how many bytes to read from that position. The abstraction could then track how many bytes of the body have been written and stop when needed.

Using this abstraction, HTTP range requests could be implemented by simply using this function multiple times for each part of the response. Writing the intermediate headers can be done inside the HTTP loop, with no user interaction required.

This will probably require #33 first, as the response step that writes the headers conflicts with the idea to remove response steps alltogether.

I just had a thought on how this could be implemented. The concept of response steps was introduced to allow custom code to write the response body, e.g. streaming the data from a store entry. However, this might be the wrong way to solve this. Instead, we could introduce a "data reader" function that can be configured for each route. The signature of this function would include a buffer to write to, an index inside the response body from which to read, and how many bytes to read from that position. The abstraction could then track how many bytes of the body have been written and stop when needed. Using this abstraction, HTTP range requests could be implemented by simply using this function multiple times for each part of the response. Writing the intermediate headers can be done inside the HTTP loop, with no user interaction required. This will probably require #33 first, as the response step that writes the headers conflicts with the idea to remove response steps alltogether.

Jef Roosens added the

Project/Lander

label 2024-08-26 10:42:18 +02:00