Hi again. For completeness, I'm going to update my haproxy fork with three commits that correspond to what you suggested. See them attached and hopefully they should fit the bill ๐.
I added a minor fix to avoid a warning on a possible null pointer in this snippet of syslog_fd_handler(): struct listener *l = objt_listener(fdtab[fd].owner); struct proxy *frontend; int max_accept; BUG_ON(!l); frontend = l->bind_conf->frontend; /* <-- moved this assignment after BUG_ON */ Cheers, Rober --- Roberto Moreda Allenta Consulting<http://www.allenta.com> (+34 881922600) Privacidad / Privacy<http://allenta.com/mail-privacy> On Mar 3, 2025, at 19:08, Roberto Moreda <mor...@allenta.com> wrote: If you don't mind to split the patches (or even edit details), please go ahead. Credit is always shared ๐. I meant that my original idea was slightly different and it was through dialogue that we found the good one ๐. Thx a lot. Enviado desde dispositivo mรณvil. Sent from mobile device. --- Roberto Moreda Allenta Consulting http://allenta.com On 3 Mar 2025, at 18:56, Roberto Moreda <mor...@allenta.com> wrote: ๏ปฟ + +#define PR_O2_DONTPARSELOG 0x02000000 /* don't parse log messages */ +#define PR_O2_ASSUME_RFC6587_NTF 0x04000000 /* assume that we are going to receive just non-transparent framing messages */ /* unused : 0x0000000..0x80000000 */ I would add a small note in the comments to mention that they are log-proxy specific. Also the 0x01000000 may be used instead of 0x04000000. Plus the "unused" comment below them should be updated. Maybe I'm wrong, but note that the previous lines in the file are: #define PR_O2_RSTRICT_REQ_HDR_NAMES_BLK 0x00400000 /* reject request with header names containing chars outside of [0-9a-zA-Z-] charset */ #define PR_O2_RSTRICT_REQ_HDR_NAMES_DEL 0x00800000 /* remove request header names containing chars outside of [0-9a-zA-Z-] charset */ #define PR_O2_RSTRICT_REQ_HDR_NAMES_NOOP 0x01000000 /* preserve request header names containing chars outside of [0-9a-zA-Z-] charset */ #define PR_O2_RSTRICT_REQ_HDR_NAMES_MASK 0x01c00000 /* mask for restrict-http-header-names option */ I used 0x02000000 and 0x04000000 to avoid collisions โwe don't want a future where PR_O2_RSTRICT_REQ_HDR_NAMES_NOOP could be used side-to-side with PR_O2_ASSUME_RFC6587_NTF 0x04000000โ. Also, the "unused" comment seems not updated originally because I guess is just a hint on the fact that 0x80000000 and on are "reserved". Just let me know about this and I'll patch the patch ๐. If you don't mind to split the patches (or even edit details), please go ahead. Credit is always shared ๐. Thx! Rober --- Roberto Moreda Allenta Consulting<http://www.allenta.com/> (+34 881922600) Privacidad / Privacy<http://allenta.com/mail-privacy> On Mar 3, 2025, at 18:41, Aurelien DARRAGON <adarra...@haproxy.com> wrote: On 3/3/25 17:37, Roberto Moreda wrote: Thank you for sharing your thoughts, I really appreciate it. I do really like the idea of having a regular frontend section with "mode log" in the future. Considering this, I fully agree on the approach that you suggest. Notes: * The new two options take two bits in the proxy->options2. * I replicate the loop to read options as it is in cfgparse-listen.c (only over options2). I added an explicit initialization px->options2 = 0. Great, thanks for the quick turnaround! It looks good to me. Just a few minor things: + +#define PR_O2_DONTPARSELOG 0x02000000 /* don't parse log messages */ +#define PR_O2_ASSUME_RFC6587_NTF 0x04000000 /* assume that we are going to receive just non-transparent framing messages */ /* unused : 0x0000000..0x80000000 */ I would add a small note in the comments to mention that they are log-proxy specific. Also the 0x01000000 may be used instead of 0x04000000. Plus the "unused" comment below them should be updated. I'm attaching the new patch. I you prefer me to split it (or any other change), just let me know. If you can split the patches (one for the options eval in cfg_parse_log_forward()), one for prepare_log_message() and the last one with the actual options, it would be super! I can do that on your behalf if you want though :) Thanks!
0001-MEDIUM-log-add-options-eval-for-log-forward.patch
Description: 0001-MEDIUM-log-add-options-eval-for-log-forward.patch
0002-MINOR-log-detach-prepare-from-parse-message.patch
Description: 0002-MINOR-log-detach-prepare-from-parse-message.patch
0003-MEDIUM-log-add-dontparselog-and-assume-rfc6587-ntf-o.patch
Description: 0003-MEDIUM-log-add-dontparselog-and-assume-rfc6587-ntf-o.patch
