Support for X-SendFile/X-Accel

[myers]

I have a number of self hosted projects where I would like to serve large media files, but only to authenticated users. If this was a large website I would reach for something like AWS S3 with timed access tokens, but I want all the files locally. If I where to put nginx in front of my python site I would use X-Accel so that my python code could assure that the user has access, then allow nginx to copy the file to the socket.

This would be great for my applications I want to put in docker containers with granian as the only process.

Would there be any interest in a PR that implements this for granian? Thanks!

[myers]

After poking about in the code, I see RSGI has a response_file. Looking at serving a django app with RSGI

[gi0baro]

🤔 why can't you just keep your setup the same also with Granian? You can switch from whatever server you use with nginx and your code can still return the X-Accel headers relying on nginx for serving such requests..

As for RSGI, Django doesn't support that, so it's not really an option IMHO.

[myers]

I would, and I think this is a common need, like to simplify how my python apps are deployed. I deploy to a k8s cluster, building my app in a docker image. Currently, to do this correctly you need:

1. a init system that would handle zombie processes
2. nginx to handle static files. I don't need this for protection from slow loris or other types of attack, because once the docker container is running all http requests go to a k8s ingress controller, which is often another copy of nginx.
3. gunicorn

My hope is that with Granian I could have

1. replace the init system by having granian handle zombie processes: https://www.fpcomplete.com/rust/pid1/ (I haven't digested this fully yet). Maybe with https://crates.io/crates/pid1?
2. Granian could serve static files without blocking a python interpreter
3. Granian replaces gunicorn

For non streaming responses from django, it would seem like a simple shim between the WSGI django app to RSGI would work.

[gi0baro]

Here are my considerations:

1. replace the init system by having granian handle zombie processes: https://www.fpcomplete.com/rust/pid1/ (I haven't digested this fully yet). Maybe with https://crates.io/crates/pid1?

I work with kubernetes too, and never used an init system inside the containers. I see no real value in using supervisors inside kubernetes where you can just rely directly on the server as the entry point and let kubernetes restart the pod when something happens to its main process. In case of worries about the main process stalling, I think using health checks its simpler.

2. Granian could serve static files without blocking a python interpreter

That's already the case for RSGI protocol, while for ASGI there's #82 in pipeline. No plans for WSGI as the protocol itself offers no options other than hacks on headers/environ checks.

I'm not sure implementing hacks coming from other general-purpose servers like Nginx belongs to the scope of the project. But we can have a discussion about that.

3. Granian replaces gunicorn

This is what granian does already :)

For non streaming responses from django, it would seem like a simple shim between the WSGI django app to RSGI would work.

I'm not sure it would be so easy, as RSGI is an async protocol like ASGI, whereas WSGI is synchronous. But if you find a quick way sounds like a good opportunity to release a django extension which adds support for RSGI :)