Hello, On Mon, Mar 30, 2026 at 7:20 PM Willy Tarreau <[email protected]> wrote: > > 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
I think I covered everything suggested, function has been renamed to is_immutable_header, I updated the docs referencing the lack of parser validation and the max number of headers. I've also added the prefix keyword that will allow set/add-headers-bin to only add those headers matching the prefix. New patch attached. Regards, Nenad
0001-MEDIUM-Add-set-headers-bin-add-headers-bin-and-del-h.patch
Description: Binary data
