Proposal: introduce `http.response.pathsend` extension

[gi0baro]

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: https://github.com/emmett-framework/granian/issues/82

[andrewgodwin]

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]

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