WorkerExtensionStartup registers Middleware before ConfigureFunctionsWebApplication when using Http.AspNetCore about azure-functions-dotnet-worker HOT 5 OPEN

@swettstein AspNetCore registration is also an extension using the same hook as your example. We offer no ordering control for this way of registering middleware, so this would be a new feature to offer that ability via the attribute route.

For now, if you need to control the middleware timing, users will need to register it during ConfigureFunctionsWorkerDefaults callback - as that will happen after extension middleware is automatically registered.

from azure-functions-dotnet-worker.

controlling the order of extension middleware would be a nice feature but there is some complexity there and probably not necessary in this case.

the AspNetCore extension doesn't use WorkerExtensionStartup but rather depends on users correctly applying an extension method from FunctionsHostBuilderExtensions. none of the other built-in extensions operate this way so why is this one different?

why couldn't the AspNetCore extension be internally smarter about how it gets registered by ensuring that its middleware gets inserted first?

from azure-functions-dotnet-worker.

Keeping this item in the backlog, as it is a valid request/gap, but this is low priority and there are no plans to have this worked on at the moment.

from azure-functions-dotnet-worker.

the AspNetCore extension doesn't use WorkerExtensionStartup but rather depends on users correctly applying an extension method from FunctionsHostBuilderExtensions. none of the other built-in extensions operate this way so why is this one different?

The reason for this comes down to needing access to the IHostBuilder, which WorkerExtensionStartup does not offer.

why couldn't the AspNetCore extension be internally smarter about how it gets registered by ensuring that its middleware gets inserted first?

For the same reason other extensions do not control order of middleware: there is no API for that. The extension only accesses public APIs from our worker assemblies, so it has no more privilege at setting a middleware first than any other extension does.

Addressing both of these points would require a non-trivial overhaul of some of our public APIs - which is not a priority at this point.

from azure-functions-dotnet-worker.

The reason for this comes down to needing access to the IHostBuilder, which WorkerExtensionStartup does not offer.

Some of it needs access to IHostBuilder but adding the FunctionsHttpProxyingMiddleware does not. It happens in an extension of IFunctionsWorkerApplicationBuilder which is accessible from WorkerExtensionStartup. regardless, with no guaranteed ordering of loading Extension Startups, the only way to guarantee my custom middleware is after the proxying middleware is to register it in ConfigureFunctionsWebApplication like i've already done for the workaround above.

i agree setting middleware priority would be non-trivial, especially when some of them are anonymous delegates. but what may be easier to do is priority of WorkerExtensionStartup through additional properties on the WorkerExtensionStartupAttribute. either way it's not high on your priority list.

ultimately if i'm creating an extension that's dependent on another extension, i would like to control the timing/ordering within my extension rather than depending on end users to get it right.

from azure-functions-dotnet-worker.