Change DefaultFiles/DirectoryBrowser/StaticFileMiddleware to only no-op if there's an active endpoint with a non-null RequestDelegate
DamianEdwards opened this issue · comments
The DefaultFilesMiddleware, DirectoryBrowserMiddleware, and StaticFileMiddleware currently no-op (fall through to the next middleware in the pipeline) if they detect the request has an active endpoint (see code here).
This prevents the middleware from running even in cases where there's an endpoint with a null RequestDelegate. This prevents the ability to have an active endpoint for the purposes of communicating metadata to middleware while allowing middleware like the StaticFileMiddleware to keep performing its function, e.g. have a "dummy" endpoint to carry IAuthorizeData metadata so that the AuthorizationMiddleware performs authorization on a request before the StaticFileMiddleware runs (example here).
We should consider updating the check in these middleware to instead only no-op if the active endpoint's request delegate is null, i.e.:
// Return true because we only want to run if there is no endpoint request delegate.
private static bool ValidateNoEndpointRequestDelegate(HttpContext context) => context.GetEndpoint()?.RequestDelegate == null;If there are other middleware with similar behavior we should consider updating those in a similar fashion.
@Tratcher @davidfowl @JamesNK any thoughts if this would cause any issues?
Could RequestDelegate ever be null before?
Endpoint.RequestDelegate is marked as nullable, so yes?
Sure, but in practice where there any situations where it was null that we would now handle differently?
Not that I'm aware of, but that's impossible to prove absolutely. Is your question basically "Are there cases where the middleware would now start handling the request where before it didn't?"
Right. If a null RequestDelegate was common for some situation before, those requests could now collide with StaticFiles. If this wasn't a pattern we saw in use before then the change is harmless.
I'll let the others chime in on that then, given I only found out today that Endpoint.RequestDelegate could even be null 😃
I am supportive of this change. It opens up something we're trying to do with endpoints and policies. An endpoint without a request delegate is pretty rare which is why I feel comfortable taking this one. It is a breaking change though, so maybe its worth documenting anyways.
Do we feel it warrants an appcontext switch (I'm guessing... no)?
Do we feel it warrants an appcontext switch (I'm guessing... no)?
Triage - we don't think it needs one. If we can get this in for preview7 without breaking anybody, we say go ahead