Feature request: `invoke` handler
legobeat opened this issue · 2 comments
It is often the case that we want to do some further handling of a request after termination with caddy-l4. One example would be using the caddy http module to match on HTTP headers, rewrite URLs, or conditionally forward to different downstreams.
We do have some existing overlap of functionality in the l4.http module but it doesn't seem desirable to start lifting over further "missing functionality" from caddy into l4, or as a user to fork it for this purpose.
Currently, I see two ways to achieve this without modifying caddy-l4:
- Putting caddy-l4 in
listener_wrappers, wrapping downstream listeners- I have not tried this but seems working: #102
- This seems to be the idiomatic way?
- Have a separate
httpapp running on a local socket and have caddy-l4dialit- This works fine and is relatively trivial to configure but is inefficient and ugly
If caddy-l4 adds support for an invoke handler matching the API of the http app and forwarding to named routes from other apps, it seems that we could get a nice middle-ground option which:
- matches Caddy API
- is relatively less complex than using
listener_wrappers - shouldn't need accommodating for protocol particularities or larger changes in caddy-l4
Possibly at some point later I could take a stab at an early implementation if I could get a sanity-check on the above assumptions and suggested approach.
Related:
Have a separate http app running on a local socket and have caddy-l4 dial it
- This works fine and is relatively trivial to configure but is inefficient and ugly
A while ago I experimented with making a listener that can "pipe" data directly within the process, without the inefficiencies of re-dialing: caddyserver/caddy#5040
It seems like that would go a long way to fulfilling the feature request?