No apparent way to use async APIs in route/service guards

[ssokolow]

trafficstars

Expected Behavior

I should have a way to create route/service guards which use functions like tokio::fs::canonicalize in a guard.

Current Behavior

I have to reimplement part of the router in a single default route to work around the inappropriateness of using std::fs::canonicalize in an async server, which currently has me going down a rabbit hole of how extractors are implemented and what FromRequest code to copy into my own functions while trying to make some code into a reusable framework to share between several projects so I don't have to make an unmaintainable mess of macro_rules! and $foo::tt to do it.

Possible Solution

Option 1 (more generally applicable): Add Scope::guard_async and Route::guard_async

Option 2 (potentially a rabbit hole of "more extension points here too, please"): Since I'm basically bypassing and re-implementing actix_files::FilesService to customize the directory listings and add programmatic whitelisting to the file-serving route, add a method to override the directory-rendering function and add support for async guards on the file-serving portion of actix_files::FilesService.

Steps to Reproduce (for bugs)

1. Read the docs and notice the type signature on Scope::guard and Route::guard lacks an async and there are no apparent async counterparts.

Context

I'm implementing various tools that are variations on the actix_files::FilesService concept, but going beyond what it's capable of in three ways (so far), and I'm trying to deduplicate the code between them... and trying not to make an unmaintainable mess of macro_rules! in the process:

1. Custom directory listings

   • A "like miniserve, but an image gallery" tool with a grid of thumbnails that are generated and stored in the XDG Thumbnail Managing Standard cache on-demand using a thread pool connected to the actix-web executor via an async-able channel for a job queue and tokio::sync::oneshot to make thumbnailing completion awaitable.
   • A more traditional mod_autoindex-esque file server that themes its contents up to look like a MacOS Finder window or a Windows 9x Explorer window or a Windows 3.1x Program Manager (category lists) of File Manager (file lists) window or the like, for use on my airgapped retro-hobby LAN.

2. Whitelisting files allowed to be served (eg. the image gallery imposes permission restrictions on which directories may be listed and only allows certain file types to be served verbatim.)

3. Interspersing static and non-static files (eg. so the URLs in the address bar stay nice and clean, non-mod_autoindex routes go under /_/ while mod_autoindex routes go directly in the site route. (i.e. /_/base.css served from rust-embed and /served_file.png served dynamically as a actix_files::NamedFile.)

In the future, I may also explore replacing some/all of the folder listings with something more dynamic (eg. When I get to DOS, I may want to mimic XTree Gold and generate/maintain a cache of a recursive traversal of the filesystem, or I may want to say, if /foo/bar contains a .index.sqlite3, then query that to build the listing instead of using file-listing so I don't have to maintain a forest of symlinks.), which is part of the reason I thought this would work better as async guards than extending FilesService.

Your Environment

• Actix Web Version: docs.rs/actix-web/latest, which appears to be 4.2.1