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

WSGI sendfile support (wsgi.file_wrapper) #434

Closed
edmorley opened this issue Nov 19, 2024 · 2 comments
Closed

WSGI sendfile support (wsgi.file_wrapper) #434

edmorley opened this issue Nov 19, 2024 · 2 comments
Labels
wontfix This will not be worked on wsgi Issue related to WSGI protocol

Comments

@edmorley
Copy link

Hi!

The WSGI spec includes support for optional platform-specific file handling support via wsgi.file_wrapper:
https://peps.python.org/pep-3333/#optional-platform-specific-file-handling

This can be used to improve performance of serving files - for example, by using sendfile() on Unix.

This is supported by gunicorn:
https://github.com/benoitc/gunicorn/blob/bacbf8aa5152b94e44aa5d2a94aeaf0318a85248/gunicorn/http/wsgi.py#L359-L390

...and when paired with eg WhiteNoise, allows for Django static assets to be served in a fairly efficient way in environments where use of a separate nginx proxy is not possible or desired.

As such, it would be great if Granian's WSGI interface supported it too :-)

@gi0baro gi0baro added the wsgi Issue related to WSGI protocol label Nov 19, 2024
@gi0baro
Copy link
Member

gi0baro commented Nov 19, 2024

As of today there's no support for sendfile(2) in tokio – and consequentially in hyper. Thus, even if Granian would provide a file_wrapper implementation, it won't have any noticeable performance benefit compared to reading the file in Python and iterate over its contents.

Note that this is also the same reason why ASGI zero copy send is marked as inapplicable in #93.

@gi0baro gi0baro closed this as completed Nov 19, 2024
@gi0baro gi0baro added the wontfix This will not be worked on label Nov 19, 2024
@edmorley
Copy link
Author

@gi0baro Could you update the status of this issue to the new GitHub "wontfix" status, instead of the standard "closed"? It makes it clearer when viewing issues in eg search results that the feature wasn't implemented. See:
https://github.blog/changelog/2022-05-19-the-new-github-issues-may-19th-update/#%F0%9F%95%B5%F0%9F%8F%BD%E2%99%80%EF%B8%8F-issue-closed-reasons

@gi0baro gi0baro closed this as not planned Won't fix, can't repro, duplicate, stale Nov 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on wsgi Issue related to WSGI protocol
Projects
None yet
Development

No branches or pull requests

2 participants