Since this was brought up, > On 7 Oct 2023, at 14:34, Willy Tarreau <w...@1wt.eu> wrote: > > […] > >> Maybe this will then bring up SPOE to a level where the body of a request >> can be scanned and bring it to a full WAF level or as WASM filter.
Any thoughts on the feasibility of a WASM based alternative to the current LUA platform? From what I looked there are a few WASM runtimes set up for being embedded in C applications, though I’m not expert enough on the tradeoffs of each to know if there are dealbreakers. I also realize that a lot of work went into the current LUA support (a long at the frighteningly long .c file for it speaks volumes). But on one hand I find it rather difficult to use correctly in its current state, in part because of the complete absence (to my knowledge) of something equivalent to C headers for validation ahead of deployment, and also in part (and more personally) because I never understood what anyone could possibly like about LUA itself… > […] > >> Are there any plans to have something similar to XDS ( >> https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol ) for >> dynamic configs at runtime, similar to the socket api and Data Plane API? > > I used to have such plans a long time ago and even participated to a > few udpapi meetings. But at this point I think it's not haproxy's job > to perform service discovery And that’s a very fair point. I wonder however how feasible it will realistically be from dpapi’s perspective to add that to its remit. That said I’d definitely be very interested as well. As much as handcrafted configurations are nice, one quickly reaches their maintainability limits. And if we’re to stop abusing DNS again and again, proper service discovery is the way. Tristan
