]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MINOR: log: fix CBOR encoding with LOG_VARTEXT_START() + lf_encode_chunk()
authorAurelien DARRAGON <adarragon@haproxy.com>
Mon, 7 Apr 2025 10:00:03 +0000 (12:00 +0200)
committerAurelien DARRAGON <adarragon@haproxy.com>
Mon, 7 Apr 2025 10:27:14 +0000 (12:27 +0200)
commit9e8444b730e9b24e73f1f78d269f5001a34bd98d
tree1102edff842e36ba241208c936f459e16bca8983
parentf01ff2478f674671df75e011f428e0abf794d3dc
BUG/MINOR: log: fix CBOR encoding with LOG_VARTEXT_START() + lf_encode_chunk()

There have been some reports that using %HV logformat alias with CBOR
encoder would produce invalid CBOR payload according to some CBOR
implementations such as "cbor.me". Indeed, with the below log-format:

  log-format "%{+cbor}o %(protocol)HV"

And the resulting CBOR payload:

  BF6870726F746F636F6C7F48485454502F312E31FFFF

cbor.me would complain with: "bytes/text mismatch (ASCII-8BIT != UTF-8) in
streaming string") error message.

It is due to the version string being first announced as text, while CBOR
encoder actually encodes it as byte string later when lf_encode_chunk()
is used.

In fact it affects all patterns combining LOG_VARTEXT_START() with
lf_encode_chunk() which means  %HM, %HU, %HQ, %HPO and %HP are also
affected. To fix the issue, in _lf_encode_bytes() (which is
lf_encode_chunk() helper), we now check if we are inside a VARTEXT (we
can tell it if ctx->in_text is true), in which case we consider that we
already announced the current data as regular text so we keep the same
type to encode the bytes from the chunk to prevent inconsistencies.

It should be backported in 3.0
src/log.c