]> git.kaiwu.me - haproxy.git/commit
REGTESTS: log: check which log-format tags escape control characters
authorWilly Tarreau <w@1wt.eu>
Tue, 1 Sep 2026 14:23:08 +0000 (16:23 +0200)
committerWilly Tarreau <w@1wt.eu>
Thu, 3 Sep 2026 05:54:51 +0000 (07:54 +0200)
commitf0cdc4e9f316d30cabfe257631163502303c25bb
treea298e41c439d55504f0c0b76340c7054ebff174b
parentc6f8f5e0108ae0e8ae27bff21a21e4b393ace533
REGTESTS: log: check which log-format tags escape control characters

It is not obvious which log-format construct protects the log against
control characters coming from the request, and "+E" is easily believed
to be the one, while it is in fact the RFC5424 structured-data escaping
and only covers '"', '\' and ']' (see rfc5424_escape_map).

The test logs one same captured header value, containing a raw ESC and a
']', through three different tags, and shows that:

  smp |A?[31m]B|        %[capture.req.hdr(0)]      nothing escaped
  esc |A?[31m\]B|       %{+E}[capture.req.hdr(0)]  ']' escaped, not the ESC
  hdr |{A#1B[31m]B}|    %hr                        ESC encoded as "#1B"

Only %hr and %r, which use hdr_encode_map and url_encode_map, encode the
0x00-0x1f and 0x7f-0xff ranges. A sample expression emits them verbatim
whatever the options, so a config using %[...] to log request data puts
control characters in the logs and in the rings.

The dump is read with "show events -s" so that a control character which
made it to the ring shows up as a '?', which avoids embedding one into
this file. The test does not depend on the delimiter fix from the two
previous commits since it does not use "-0".
reg-tests/log/log_escaping.vtc [new file with mode: 0644]