Hi Christopher, Thanks for the quick review!
> If the event is triggered just before the switching rules, it should > probably be named "on-switching-rules". "on-frontend-tcp-request-done" > is ambiguous if used on an HTTP frontend [...] Agreed, that's clearer. v2 renames the event to "on-switching-rules" (enum SPOE_EV_ON_SWITCHING_RULES) throughout, including the reg-test. > In addition, the new event must be listed in the "event" directive > documentation. Done. v2 adds it to the "event" directive list in addition to the "Events & Messages" section. > I guess the 3 patches can be merged into one. Merged into a single patch now in v2. > As a side note, a workaround to your issue would be to use a > "send-spoe-group" action at the right place in your "tcp-request > content" ruleset. That also did the trick for our use case. Thank you very much for the tip. In general, we still think this patch would be nice to have. Thanks, Benedict + Alexander From: Christopher Faulet <[email protected]> Date: Monday, 5. October 2026 at 08:04 To: Stephan, Alexander <[email protected]>; [email protected] <[email protected]> Cc: Weis, Benedict <[email protected]> Subject: Re: [PATCH 0/3] MEDIUM: spoe: add the "on-frontend-tcp-request-done" event [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Le 29/09/2026 à 11:12 AM, Stephan, Alexander a écrit : > Hi list, > > This series adds a new SPOE event, "on-frontend-tcp-request-done", which > fires on the frontend after the "tcp-request content" rules have been > evaluated but before the "use_backend" switching rules. This lets an SPOA > agent inspect the buffered request and influence backend selection, for > example by setting a variable that a "use_backend" rule then reads. > > The motivating use case is SNI-based routing in TCP mode: waiting for the > request via "tcp-request inspect-delay" + "tcp-request content", handing > req.ssl_sni to an agent, and letting the agent's reply pick the backend. > > The event is hooked on the AN_REQ_SWITCHING_RULES analyzer through the > filter pre-analyze callback, so it runs after tcp_inspect_request() and > before process_switching_rules(). Its sample-fetch validity checkpoint is > SMP_VAL_FE_SET_BCK, matching the point at which use_backend rules are > evaluated. Like the other frontend events, it is only accepted for SPOE > filters declared in a frontend/listen section. > > Patch 1 implements the event, patch 2 documents it, and patch 3 adds a > functional reg-test driven by a minimal stdlib-only SPOA mock, avoiding > external > dependencies. > > The patches also resolve GH issue > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhaproxy%2Fhaproxy%2Fissues%2F3220&data=05%7C02%7Calexander.stephan%40sap.com%7C722da0d4c6ae4e0b8c8708df22a68561%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C639267770756547436%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=RUfLym%2BfnJsVN%2BNIGS8AQ55XlrarOAP8NKBr92NHtIU%3D&reserved=0<https://github.com/haproxy/haproxy/issues/3220> > <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhaproxy%2Fhaproxy%2Fissues%2F3220&data=05%7C02%7Calexander.stephan%40sap.com%7C722da0d4c6ae4e0b8c8708df22a68561%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C639267770756579167%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=%2BCOhMQ11hRBkVT21f0r34Yx0pfW6SLaz%2FxLsKaJOLvg%3D&reserved=0<https://github.com/haproxy/haproxy/issues/3220>>. > Hi, Thanks. Just a comment. If the event is triggered just before the switching rules, it should probably be named "on-switching-rules". "on-frontend-tcp-request-done" is ambiguous if used on an HTTP frontend because we don't know when it is triggered in relation to on-frontend-http-request. In addition, the new event must be listed in the "event" directive documentation. I guess the 3 patches can be merged into one. As a side note, a workaround to your issue would be to use a "send-spoe-group" action at the right place in your "tcp-request content" ruleset. Regards, -- Christopher Faulet
v2-0001-MEDIUM-spoe-add-the-on-switching-rules-event.patch
Description: v2-0001-MEDIUM-spoe-add-the-on-switching-rules-event.patch
