On Mon, Mar 30, 2026 at 06:10:50PM +0200, Christopher Faulet wrote: > Le 30/03/2026 à 5:27 PM, Nenad Merdanovic a écrit : > > Hello Christopher, > > > > Would that be optional or are you saying it should always work like > > that? The reason I'm asking is that doing it that way kind of defeats > > the purpose of the feature which is that SPOA needs to be able to set > > arbitrary headers. If we make it always work that way, you would still > > need to strip the prefix for headers that you want SPOA to rewrite or > > insert that you want the origin to understand correctly (think > > Host/Authorization/various signature headers, etc.) > > > > In my mind it is the SPOA is responsible for managing what kind of > > headers it allows to be inserted/changed. If what you're saying is > > having an option to add the prefix to each header, I can build that > > in. > > > Well, it can be optional of course. The idea is to let the user decides if > he 100% trusts the SPOA (or more generally the producer of these headers) or > not. It is the same than for the "var-prefix" SPOE option and > "register-var-names" / "force-set-var" SPOE directives. > > I would say that ideally it could also be nice to exclude some header names. > But it could be a bit hard to configure and probably overkill. So a filter > on a prefix is a good alternative I guess. > > My first idea was to only insert headers with a name matching a prefix. > Forcing this way the SPOA to use this prefix. But it could also be a prefix > to add to each header names. It may be easier.
I think it would be more difficult to maintain agents in a good working state if a prefix was inserted, because anyway in the return traffic the agent would have to know the real header name, and having to deal with both versions (with and without prefix) while another part is also in haproxy's config could quickly become a nightmare. Based on experience of something I had done in the past, matching a prefix is convenient: you just mention the rules to agent/application developers and only the conforming ones match. It also avoids accidental leaks the day an agent copies headers directly from another HTTP source. And when the agent is totally trusted (which is often the case in many places), having an empty prefix to implicitly allow everything works perfectly fine as well. Willy
