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

Proposal: introduce http.response.pathsend extension #404

Closed
gi0baro opened this issue Aug 23, 2023 · 2 comments · Fixed by #407
Closed

Proposal: introduce http.response.pathsend extension #404

gi0baro opened this issue Aug 23, 2023 · 2 comments · Fixed by #407

Comments

@gi0baro
Copy link
Contributor

gi0baro commented Aug 23, 2023

Some ASGI servers might not be able to implement http.response.zerocopysend extension due to specific implementation constraints, for instance Rust implemented servers like Granian won't play well with file descriptors.

Nevertheless, such servers might still be able to directly serve files with "zero copy" techniques when the source path is known in advance. For instance, Granian already provide such feature within the RSGI protocol, offering ~28x performance increase over standard file serving in ASGI.

Given this dramatic performance gain, it would be nice to introduce a similar approach also in ASGI, applying the same offloading technique for such kind of contents, where the server itself is the sole responsible of processing the files. And this is the aim of this proposal: introduce an extension quite similar to http.response.zerocopysend but based on paths rather than file descriptiors.

The idea is to add a pathsend extension which the server can list in the appropriate key of the scope:

"scope": {
    ...
    "extensions": {
        "http.response.pathsend": {},
    },
}

With the above extra definition, a new event can be produced by ASGI applications, with the following keys:

  • type (Unicode string): "http.response.pathsend"
  • pathsend (Unicode string): The string representation of the file path to serve (platform specific)

which will instruct the server to serve the file directly from the relevant path.

A couple of details worth to mention:

  • in this design, the ASGI application is still responsible to send the http.response.start event with the relevant headers (eg: content-type, content-length, etc.)
  • the path should be absolute, or when relative would be relative to the current working directory the server was started

Once we discussed this properly, and if it makes sense, I'm up to open a PR with the relevant changes.
Reference of the Granian issue: emmett-framework/granian#82

@andrewgodwin
Copy link
Member

I think this is a reasonable idea - I'd quite like it to match zerocopysend as close as possible, but your proposal basically does, so that's good. I'd probably also say absolute paths only, just because relative paths are going to be messy?

I might want a different name, though, since file_path is quite generic. Maybe pathsend to have a bit of name similarity?

@gi0baro
Copy link
Contributor Author

gi0baro commented Aug 26, 2023

I'd probably also say absolute paths only, just because relative paths are going to be messy?

I think as soon as the convention is clear it doesn't really makes a big difference. But I also see the point of keeping the reference as simple as possible.

I might want a different name, though, since file_path is quite generic. Maybe pathsend to have a bit of name similarity?

Make sense. I gonna update the title and description of the issue accordingly

@gi0baro gi0baro changed the title Proposal: introduce http.response.file_path extension Proposal: introduce http.response.pathsend extension Aug 26, 2023
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

Successfully merging a pull request may close this issue.

2 participants