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. Regards, Nenad On Mon, Mar 30, 2026 at 4:35 PM Christopher Faulet <[email protected]> wrote: > > Le 27/03/2026 à 10:03 AM, Christopher Faulet a écrit : > > Le 03/02/2026 à 1:47 AM, Nenad Merdanovic a écrit : > >> Hello, > >> > >> I would like to discuss the possibility of adding a feature to set/add > >> multiple headers in the same http-request/response command and the > >> best way to implement that. > >> > >> The main driver behind this is being able to return any number of > >> headers with names unknown in advance from SPOA that would then be set > >> by HAProxy, both upstream and downstream. > >> > >> A consideration has to be made that some headers must not be reset. > >> The list I came up with is: connection, content-length, expect, > >> keep-alive, proxy-authenticate, proxy-authorization, proxy-connection, > >> trailer, transfer-encoding, upgrade. If anyone has any additions, > >> please let me know. > >> > >> I made a very rough patch that seems to do what I want it to do, but > >> lacks boundary checking and header name filtering, etc. Figured I'd > >> get some comments before spending too much time on this. The patch > >> adds two new keywords to the HTTP actions, set-headers-bin and > >> add-headers-bin. The input is a base64 encoded string created by > >> varint encoding the headers, ie. the same encoding used by > >> req.hdrs_bin. Also now I noticed the patch doesn't properly free > >> "decoded" trash chunk, but that will be fixed before I send a final > >> patch, so it can be ignored. > >> > >> Quick test I made with this config: > >> http-request set-var(txn.oldheaders) req.hdrs_bin,base64 > >> http-request del-header Accept > >> http-request del-header User-Agent > >> http-request del-header Host > >> http-request set-headers-bin %[var(txn.oldheaders)] > >> http-request set-var(txn.endheaders) req.hdrs_bin > >> http-after-response set-header Old %[var(txn.oldheaders)] > >> http-after-response set-header End %[var(txn.endheaders)] > >> > >> Seems to show expected results, as the deleted headers are correctly > >> restored: > >> > >> HTTP/1.1 200 OK > >> content-length: 0 > >> old: > >> BGhvc3QPbG9jYWxob3N0OjEwMDAwCnVzZXItYWdlbnQLY3VybC84LjExLjEGYWNjZXB0AyovKgAA > >> end: %04host%0Flocalhost:10000%0Auser-agent%0Bcurl/8.11.1%06accept%03*/* > >> > >> Regards, > >> Nenad > > > > > > Hi Nenad, > > > > Very sorry for the delay ! > > > > Your patch seems quite clean. If you agree, I suggest to rename > > is_forbidden_header() function, to is_immutable_header() for instance. It > > better > > reflects what it does. > > > > It could be also good to add a warning for set-headers-bin/add-headers-bin > > actions. The headers were not validated by an HTTP parser. So the user must > > be > > careful and be sure to trust the producer (the SPOA for instance). Invalid > > headers could lead to emit invalid messages and in worst cases, this could > > lead > > to requests smuggling attacks. > > > > In addition, it could be good to warning about the number of headers > > inserted. > > If there are too many headers, the message could be rejected by the muxes. > > You > > can add a reference on "tune.http.maxhdr" to do so. > > > > Hi Nenad, > > Just a quick update. I discussed of this feature with Willy and it could be > good > to restrict headers addition with a prefix, to be able to ignore headers with > a > name that don't match the prefix. > > -- > Christopher Faulet >
