Static files and matching

[JamesNK]

I updated a sample to use static files + endpoints + authz. To achieve the desired result I had to write a DIY static file endpoint matcher and it got me thinking.

RANDOM THOUGHT 1

We could add configurable static file matching to UseEndpointRouting. It would be useful when you want to run the file through APIs that use endpoints, e.g. AuthorizationMiddleware. There could be a couple of modes for matching:

• The static files all live as endpoints provided by an endpoint datasource. High memory, long startup time, high perf
• Or the endpoint for a static file is created on demand. Low memory, short startup time, low perf. This is what the authz sample is doing.

app.UseEndpointRouting(routes =>
{
    routes.MapApplication();
    routes.MapStaticFiles();
});

RANDOM THOUGHT 2

UseStaticFiles today is terminal if there is a matching file. If static files have endpoints then it could disappear from 3.0 templates and the static file could be returned at the end of the request pipeline.

Would there be performance considerations from doing this? It would mean static files experience the entire request pipeline, e.g. if authentication is enabled then static file requests would be authenticated.

Alternatively UseStaticFiles could remain present in templates, and if the request was matched to a static file endpoint in UseEndpointRouting then UseStaticFiles would do nothing more than invoke the endpoint and exit.

[JamesNK]

// @davidfowl @rynowak

[Tratcher]

Yes, StaticFiles is a prime candidate for cloning to work as endpoints. In this model I'd expect MapStaticFiles to take StaticFilesOptions and that there'd be a way to add metadata for any matches, like auth policies.

Don't forget about DefualtFiles or DirectoryBrowsing.

[rynowak]

Or the endpoint for a static file is created on demand. Low memory, short startup time, low perf. This is what the authz sample is doing.

This is what I imagined. We want to check for the presence of the file in realtime (or with a cache) rather than computing them all upfront.

We might also define some wildcarding or rules so you can do multiple things.

[rynowak]

re: template/guidance update - I totally agree. There are multiple choices about how this would work and only the application developer can decide what is best.

We've had the need for this in the past though. For instance there have been a bunch of issues with the spa fallback route. Sometimes you want to write a middleware that runs when nothing was matched.

[JamesNK]

This is what I imagined. We want to check for the presence of the file in realtime (or with a cache) rather than computing them all upfront.

Would the matcher do this? Right now it only supports matching static endpoints. What do you think of supporting dynamic endpoint selection in the matcher?

We would want to match to a dynamic endpoint, potentially under a static path, e.g. use DFA to match /files and then dynamic endpoint selection would run to check the remaining path matches against a file. If it matches then the endpoint would be created, potentially using a an endpoint convention to apply metadata to the dynamically created endpoint.

[rynowak]

Would the matcher do this? Right now it only supports matching static endpoints. What do you think of supporting dynamic endpoint selection in the matcher?

I've imagined a feature like this in the past, but I don't understand why it would be needed for static files 🤷‍♂️