Allow an IFunctionFilter to modify the HTTP status code/response

IFunctionFilter (and in particular IFunctionInvocationFilter) seems to be the only mechanism by which the execution pipeline of a function can be modified in a cross-cutting way (since you can’t really access the host builder to add arbitrary middleware).

As such, it would be very useful if the filters could affect the resulting status code of a request (say in an HTTP-triggered function).

A concrete example would be checking for certain headers or access token claims, to determine if the caller has the right permissions for the invocation, and return a 401 or 403 as appropriate.

Currently, the only way to stop/abort the processing of the current request is to throw an exception from the filter, but this results in a fixed 500 error reported to the client.

Potential solutions

• Special-case a new HttpFunctionException which can provide a status code and optional status string/message, and in this case it would not be reported as a function failure.
• Extend the FunctionExecutingContext to allow the filter to signal whether further processing should happen or if it should be stopped (and with that HTTP status code result)

Potential issues

It’s obvious that not all function invocations are HTTP-triggered, so maybe this should only be applied to those. There would need to be a mechanism in the filter to check the type of function being invoked. Currently the FunctionFilterContext is not sufficiently expressive to accomodate general-purpose pipelines that can act differently depending on the current invocation features/metadata/descriptor. Perhaps the IFunctionExecutionFeature should be exposed somehow? Maybe just the FunctionDescriptor?

[stephanruhland]

You could inject IHttpContextAccessor into your IFunctionFilter implementation. The property HttpContext should allow you to modify the response. Kind regards

[litex1982]

1. Implement a custom exception, like for example an AbortRequestException.
2. Check your custom logic in the IFunctionInvocationFilter or IFunctionInvocationAttribute implementation and throw your abort exception.
3. In the implementation of the interface IFunctionExceptionFilter it can be checked if it is a Http function (httpContextAccessor.HttpContext != null) that is the source of the exception and if it is your abort exception. If yes, you can modify the response.

In that example the main part of your function should not be executed. Its just an idea 😃

Kind regards

Can you suggest how can we abort the exception in IFunctionExceptionFilter?