Hello Christopher, That is fine, I was going for maximum flexibility, but probably not needed like you say since it's practically impossible to use the log-format to create varint encoding. Removing b64 requirement is also fine. Also one thing I wanted to fix this morning that I noticed last night is that the set-headers-bin/add-headers-bin don't work with if/unless due to the issue created when I added the "prefix" keyword, so if you can also fix that while working on it, I'd appreciate it.
Thanks again, Nenad On Wed, Apr 1, 2026 at 8:07 AM Christopher Faulet <[email protected]> wrote: > > Le 31/03/2026 à 12:04 AM, Nenad Merdanovic a écrit : > > > > 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. > > Hi Nenad, > > I merged your patch, but this morning, I've a doubt. You are using a > log-format > string for the headers argument. it seems a bit overkill. A sample expression > is > probably good enough. Especially because it is a bit hard to craft it by hand > because of the varint encoding. Most of time, I guess a variable will be used. > Then, you're requesting a base64 encoding. It seems a bit strange. There is no > reason to force the argument to be encoded in base64. Especially because the > result of req.hdrs_bin and res.hdrs_bin are not base64 encoded. And b64dec > converter can still be used if necessary. > > If you agree, I would like to change the actions to rely on a sample > expression > returning a varint encoded binary string. If you want to handle it, I'm ok > too :) > > Regards, > -- > Christopher Faulet
