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>
Tue, 15 Apr 2025 20:27:00 +0000 (22:27 +0200)
commit835770200458950767d97a5409055b0d1e17b6ff
treed7ae031367413df9d980582dedcea0760084fd90
parentd03fd2d95f568f7ac004ac9264a7455c4c587956
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

(cherry picked from commit 9e8444b730e9b24e73f1f78d269f5001a34bd98d)
Signed-off-by: Aurelien DARRAGON <adarragon@haproxy.com>
(cherry picked from commit 6c042450a4465e0dea7dafbe43157f2346444a70)
Signed-off-by: Aurelien DARRAGON <adarragon@haproxy.com>
src/log.c