Re: [PR] FEATURE: Enhance handling of non-RFC conformant syslog messages

> > My rationale was to separate clearly the set of options. As I saw already two > cluttered set of flags in options and options2, I guessed it would be clearer > to create a new one and avoid unions or context-dependent meanings to save a > few bytes per config. Also I saw in struct proxy th

Re: [PR] FEATURE: Enhance handling of non-RFC conformant syslog messages

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 rep

Re: [PR] FEATURE: Enhance handling of non-RFC conformant syslog messages

>Hi! > >As discussed few weeks ago in issue #2856 , this is a PR >that adds two useful options to the log-forward section. > >``` >option dontparselog > Enables HAProxy to relay syslog messages >without attempting to parse and > restructure them, useful f

Re: [PR] FEATURE: Enhance handling of non-RFC conformant syslog messages

>> diff --git a/src/log.c b/src/log.c >> index 234f83e2426f..af9c4c704e94 100644 >> --- a/src/log.c >> +++ b/src/log.c >> @@ -5759,7 +5759,8 @@ void syslog_fd_handler(int fd) >> >> prepare_log_message(buf->area, buf->data, &level, >> &facility, metadata, &message, &size);

Re: [PR] FEATURE: Enhance handling of non-RFC conformant syslog messages

Hi, Aurelien. Sorry for the indentation issues. See the corrected patch attached. Also I declared a pointer to frontend at the top of syslog_fd_handler() to have the same access pattern as in syslog_io_handler(). Regarding your extra notes: I don't have an opinion regarding the "proxy->options

Re: [PR] FEATURE: Enhance handling of non-RFC conformant syslog messages

Ouch, my mail client messed up the quotations... :-( I hope context could help clarify mu answer. Sorry. --- Roberto Moreda Allenta Consulting (+34 881922600) Privacidad / Privacy On Mar 3, 2025, at 13:33, Roberto Moreda wrote: Hi, Aureli

Re: [PR] FEATURE: Enhance handling of non-RFC conformant syslog messages

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

Re: [PR] FEATURE: Enhance handling of non-RFC conformant syslog messages

+ +#define PR_O2_DONTPARSELOG 0x0200 /* don't parse log messages */ +#define PR_O2_ASSUME_RFC6587_NTF 0x0400 /* assume that we are going to receive just non-transparent framing messages */ /* unused : 0x000..0x8000 */ I would add a small note in the comments to mention that

Re: [PR] FEATURE: Enhance handling of non-RFC conformant syslog messages

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(): struc

Re: [PR] FEATURE: Enhance handling of non-RFC conformant syslog messages

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. --- Robe

Collaboration Opportunity

Hi, I hope you're doing well. I wanted to follow up on my previous email regarding a potential collaboration between your website and our platform in the live cam adult niche. I understand you may be busy, but I'd appreciate your thoughts on the opportunity outlined. If you need any furth