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!

[matthewgrossman]

Trying to follow across a few issues, but it seems that we never exactly resolved this (in either ASGI/RSGI), right?

This seems to be the latest w.r.t ASGI: django/asgiref#469. And latest w.r.t RSGI: #159

Is that right, or has some PR merged somewhere that enables Range header for file GETs in granian?

[gi0baro]

#159 will be merged and released in 2.6.

ASGI changes require:

• the implementation
• the protocol documentation update
• pinging any fw out there using pathsend to actually use the ranges interface

So, far from "resolved" probably.
btw, you don't need any specific support for "ranges" in Granian with an ASGI application. You simply can't use pathsend for that atm.

[matthewgrossman]

Great, thanks for the update!

Agreed that pathsend is not necessary for ranged GETs, but for performance gains (e.g having rust handle the file reading + networking) pathsend would need to be used, right?

Maybe my mental model is wrong, but here's how I understand it: The improved ASGI pathsend discussed in django/asgiref#469 would allow my ASGI app to return to granian "hey return this file with bytes [X, Y]", and then granian rust-side would handle actual streaming those bytes back to the client.

This would mean the data wouldn't have to actually flow through the python process at all, which I imagine would result in a large performance improvement?

[gi0baro]

Correct.

But, unless you're writing your app in plain ASGI, you would need the framework in use to adopt ASGI pathsend to get the performance benefit. AFAIK, the only ASGI framework with that support is Starlette (and thus FastAPI).
All of this to say, at least from my side, that ASGI pathsend extension is not at the top of my priority list :)

[matthewgrossman]

Got it, makes sense. Yep that feels pretty far away 😅 Given that we have to first get the protocol/documentation agreed upon, before any ASGI servers (granian) or frameworks (starlette) even bother working on it.

w.r.t implementation: Doesn't IMO look like the starlette changes would be too bad, seems nicely scoped to here. And based on the work in #159 I imagine it wouldn't be too bad to just wire the new pathsend+range ASGI dict to that same impl (but of course I'd defer to you on that).

I guess next step is to bump that thread in django/asgiref and try to get a proposal through? I see you have experience getting things into ASGI based on this comment django/asgiref#423 (comment). I'm happy to (attempt to) move things along

[gi0baro]

I guess next step is to bump that thread in django/asgiref and try to get a proposal through? I see you have experience getting things into ASGI based on this comment django/asgiref#423 (comment). I'm happy to (attempt to) move things along

I'd say anybody willing to add to the spec what I described in django/asgiref#469 (comment) is completely entitled to do so by opening a PR over there. Eg: this django/asgiref#407 is how pathsend was added to the ASGI spec.