Hi Alexander, On Fri, Sep 25, 2026 at 12:26:36PM +0000, Stephan, Alexander wrote: > Hi Willy, > > This small series adds support for "use-server" rules in "defaults" sections, > so that a common set of rules can be shared across all backends inheriting > from > a given defaults section, the same way "http-request" and "tcp-request" rules > already work.
No strong objection from me at this point (I have only glanced at the patch), however I'm seeing this in the doc: In a "defaults" section, only the Custom log format form is allowed, since a defaults section has no servers against which a simple name could be resolved. A simple server name is therefore rejected at parse time. Backends inheriting from such a defaults section evaluate their own "use-server" rules first, then the ones from the defaults section, which lets a set of dynamic rules be shared across several backends. while tcp-request says this: This directive is only available from named defaults sections, not anonymous ones. Rules defined in the defaults section are evaluated before ones in the associated proxy section. To avoid ambiguities, in this case the same defaults section cannot be used by proxies with the frontend capability and by proxies with the backend capability. It means a listen section cannot use a defaults section defining such rules. So it's one significant difference for users: backends apply default tcp-request rules before their own, while use-server would do the opposite. I remember that we decided that it made more sense to have generic rules first in defaults. I can see some value in using them as last resort sometimes for use-server since in the end only one will be executed, but I'm afraid that it's a real problem in terms of consistency with other rulesets. Or we may decide to forbid the combined use of the rules in backend+defaults maybe. Another point is that tcp-request rules in defaults may exclusively be used in named defaults section, and such sections are flagged as special (I don't remember the flag) so that they cannot be used both for frontends and backends. In your case, with a use-server rule in a defaults section, that would implicitly flag that session as frontend-incompatible and this should be detected (and it should exclusively be accepted inside named defaults). > Since a "defaults" section has no servers of its own, a static server name > could never be resolved there. For that reason, only the dynamic (log-format) > form is accepted, e.g.: Yep that totally makes sense, I agree. Thanks, willy
