Forgot to add the list.
> Hi,
>
> It's rsyslog on Ubuntu 22.04. Only the Payload is affected, the rest of the
> haproxy logs are correct(and always been).
> I will try to see the rsyslog options. But why only the payload to be escaped?
>
> Yes, the provided snippet was used to reproduce. I will send a full working
> copy next days.
>
> I changed the logging tool to something internal and the issue is gone, so
> more likely a rsyslog thing. But still I wonder why only the
> Payload to be escaped?
>
> Ps: I used 3.0.9 lately in my tests - for reproducing it.
>
> Dragos
>
> On Monday, March 31st, 2025 at 3:32 PM, Jarno Huuskonen
> jarno.huusko...@uef.fi wrote:
>
> > Hi,
> >
> > On 3/31/25 11:47 AM, Aurelien DARRAGON wrote:
> >
> > > On 3/28/25 01:06, Dragos Pacher wrote:
> > >
> > > > I get:
> > > > <134>1 2025-03-27T23:40:59+00:00 localhost haproxy 800275 - -
> > > > ip-here:43116 [27/Mar/2025:23:40:59.018] https-in test/server1
> > > > 0/0/0/6/6 200 160 - - ---- 1/1/0/0/0 0/0 "POST /api HTTP/1.1"
> > > > 0/-/-/\-/0 -/-/- Payload: "{"city": "SomeCity"}"
> > > > this means the json was received correctly: Payload: "{"city":
> > > > "SomeCity"}"
> > > >
> > > > But if my json has a new line inside it like this:
> > > > curl -X POST http://domain.com:80/api -H "Content-Type:
> > > > application/json" -d "$(printf '{"city":\n"SomeCity"}')"
> > > >
> > > > I get:
> > > > #012 instead of new line:
> > > > <134>1 2025-03-27T23:44:34+00:00 localhost haproxy 800275 - -
> > > > ip-here:40356 [27/Mar/2025:23:44:34.056] https-in test/server1
> > > > 0/0/0/4/4 200 159 - - ---- 1/1/0/0/0 0/0 "POST /api HTTP/1.1"
> > > > 0/-/-/\-/0 -/-/- Payload: "{"city": #012"SomeCity"}"
> > > > and my Payload: "{"city": #012"SomeCity"}" contains #012 numbers now
> > > > which the backend apps cannot make too much sense of (I don't have
> > > > control over backend apps).
> > > >
> > > > and sometimes #012#015 which corresponds to the platform that sent the
> > > > message: LF+CR or just LF.
> >
> > Are these loglines from rsyslog ? AFAIK rsyslog escapes control chars by
> > default:
> > https://www.rsyslog.com/doc/rainerscript/global.html
> > parser.controlCharacterEscapePrefix (default #) and
> > parser.escapeControlCharactersOnReceive (default on)
> >
> > -Jarno
> >
> > > I don't understand how that's possible to have haproxy escape special
> > > chars with '#' when leveraging expression to print the capture using :
> > > "%{+Q}[capture.req.hdr(0)]". I'm unable to reproduce using the provided
> > > infos under haproxy 2.6 ... 3.0
> > >
> > > The closest behavior I got so far was when I used "%hr" alias to dump
> > > captured headers, but in this case it is expected to have special
> > > characters escaped with "#".
> > >
> > > Could you please check if the provided config example was the one used
> > > to trigger the logs? Also what exact versions (2.6 and 2.8) did you test
> > > it against?
> > >
> > > > Is there a way to unescape these numbers to characters in Haproxy
> > > > alone? In my particular case I don't have control over the backend apps
> > > > so I need to 'sanitize' the json before leaving haproxy/before logged
> > > > to disk/sent to rsyslogd.
> > >
> > > Do you still mean for the logs generated by haproxy or the actual http
> > > payload relayed by haproxy?
> > >
> > > Thanks,
> > > Aurelien
> >
> > --
> > Jarno Huuskonen
