BUG/MINOR: log: LF upsets maxlen for UDP targets
A regression was introduced with 5464885 ("MEDIUM: log/sink: re-work
and merge of build message API.").
For UDP targets, a final '\n' is systematically inserted, but with the
rework of the build message API, it is inserted after the maxlen
limitation has been enforced, so this can lead to the final message
becoming maxlen+1. For strict syslog servers that only accept up to
maxlen characters, this could be a problem.
To fix the regression, we take the final '\n' into account prior to
building the message, like it was done before the rework of the API.
This should be backported up to 2.4.
(cherry picked from commit 901f31bc9a97b972d8e36362c6f4659f42532194)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit a0211344dc13dcc3d92948c03a158d1f3460e55f)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 836c96be022230efe5b7affb7da5b9cd2e34c900)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 7916db72ff906e83254df389d16197ac49ca3326)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
1 file changed