]> git.ipfire.org Git - thirdparty/haproxy.git/commitdiff
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)
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

index 7445ada0b8fcff349c56c4a491ebbaac3b31d546..ca8716d2072636af6d2848f162b17b5602bcb80c 100644 (file)
--- a/src/log.c
+++ b/src/log.c
@@ -2266,7 +2266,7 @@ static char *_lf_encode_bytes(char *start, char *stop,
                encode_byte = _lf_map_escape_byte;
 
        if (ctx->options & LOG_OPT_ENCODE_CBOR) {
-               if (!bytes_stop) {
+               if (!bytes_stop || ctx->in_text) {
                        /* printable chars: use cbor text */
                        cbor_string_prefix = 0x60;
                }