Feature request: invoke handler

[legobeat]

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:

1. Putting caddy-l4 in listener_wrappers, wrapping downstream listeners
   • I have not tried this but seems working: Example of using http listener_wrappers with l4 #102
   • This seems to be the idiomatic way?
2. 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

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:

• Can you use the same ports as http app? #77
• Pass non terminated (SNI matched) TLS connection to http app #70
• Example of using http listener_wrappers with l4 #102
• Tunnelling legacy TLS1.0 clients to another host, terminating modern clients #119
• Non blocking matchers & matching timeout breaking l4 as a listener wrapper #207
• Collection of interesting configs #209
• Example of multiplexing ssh-over-tls to different hosts #101

[mholt]

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?

[legobeat]

@mholt Oh yeah, that looks even better, if changes to Caddy itself is on the table!