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

Ranges header support #60

Closed
ghost opened this issue Jan 27, 2018 · 2 comments
Closed

Ranges header support #60

ghost opened this issue Jan 27, 2018 · 2 comments

Comments

@ghost
Copy link

ghost commented Jan 27, 2018

This week I took a deep dive in the RFC and thought about the possibilites. I have a solution now, but I don't feel it's complete, so I need your advice about the implementation.

RFC defines two types of response when the ranges header is present: a simple one, and when you request multiple ranges which must give you back a "Multipart" response.

Implementing the latter one has the advantage of fully conforming the RFC, but has security implications(overlapping ranges, etc). The former one is much easier if you modify the Responder. In most cases it's enough. You can watch&seek a movie in your browser, also you can get a working ipxe server(this was my goal with this). Implementing this for the NamedFIle is trivial, but what if we need the ranges support for files when they come from another location.(database like MongoDB or CouchDB, S3, another webserver etc) In this case it's maybe easier to add the support in a main component.

What do you think about this and which is the preferred way for this project?

@fafhrd91
Copy link
Member

first of all let's support only NamedFile, supporting arbitrary sources is too complex, and way out of scope of this ticket.

lets add simple ranges for now. I am planing to add http client with multipart support after that adding multipart ranges would be much easier

@fafhrd91
Copy link
Member

i think #227 is enough for now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant