RSGI response_file Range header support

[myers]

Would there be a desire for http Range header support for the response_file RSGI response?

I would like to use this when serving large video files, to allow seeking within the file.

[gi0baro]

This might be hard to implement, at the moment I'm not sure we have support for this from the inner libraries used (tokio mainly). But I'm definitely up for PRs investigating this chance.

An alternative approach might be using the response_stream protocol feature and handle the read from Python itself.

[myers]

I made an attempt to implement this. My main problem is that https://github.com/emmett-framework/granian/blob/master/src/rsgi/types.rs#L221 has no access to the RSGIScope to be able to read request headers to find the range header. Just brainstorming maybe response_file could change to have another argument that gives the byte range to serve.

[myers]

Draft PR: #159

[matthiask]

I think Range header support may be interesting to have for ASGI as well. I have been looking into using Starlette's FileResponse (https://www.starlette.io/responses/#fileresponse) for static file serving, but it doesn't support the range header yet. I'm wondering if range support could be added to the ASGI pathsend extension, and if maybe the partial file serving could be left to the protocol server. I'm not sure if something like this might also help the RSGI side of things though.

[gi0baro]

@matthiask I think ASGI pathsend might be the right extension to add this feature; you can probably open up an issue/PR to asgiref and propose the changes.
I'm not sure about the implementation though, as per RSGI it is unclear to me which component should handle the headers: it feels strange to me to have the server modifying the application headers in any circumstance; so I'd probably prefer to have the involved framework/app to manage those.

[matthiask]

I'm not sure about the implementation though, as per RSGI it is unclear to me which component should handle the headers: it feels strange to me to have the server modifying the application headers in any circumstance; so I'd probably prefer to have the involved framework/app to manage those.

Yes, I agree. I think the framework/app should send back the byte ranges to serve somehow, and the protocol server should handle only the actual loading and sending of the byte ranges. In ASGI terms this could mean an additional key in the http.response.pathsend message, in RSGI terms maybe a fourth, optional argument to response_file. Not sure.

I think ASGI pathsend might be the right extension to add this feature; you can probably open up an issue/PR to asgiref and propose the changes.

Thanks, I'll probably do that in the next (few) weeks!