HTTP Trigger Binding Extensibility

[cgillum]

Summary

As part of BYOB, I would like to be able to create a trigger binding that extends the HTTP trigger binding. These custom bindings would be triggered by HTTP requests and leverage all the features of HTTP triggers (custom routing, authorization rules, etc.) but will invoke custom extension code before invoking user code.

Motivation

Durable Functions wants to add support for starting an orchestration from an HTTP request. Related issue is here. It is assumed that other trigger binding authors could benefit from this feature as well.

[paulbatum]

@cgillum Can this piggy back on the approach we used for Event Grid?

[MikeStall]

@paulbatum - likely not. There's 2 separate concepts here:

1. API-facing HTTP - public http surface area that require a significant amount of http customization (determining url, methods, routes, authentication model, show up in swagger, etc). Users provider the implementation for this (ie, their run.csx file). This is what we want to extend. This means allowing a DTF author to provide their own user code to implement the handler, but still get all the http customization powers that http trigger offers. These http endpoints are 1:1 with user unfunctions.
2. "infrastructure" http - endpoints exposed by extensions and used for extension-internal operations. These endpoints are M:N with user functions. They don't require the user to do rich http customization, and are often a opaque endpoint that gets copied into another service (like EventGrid)

This bug is about allowing customizations to the first item.