]> git.kaiwu.me - haproxy.git/commit
BUG/MEDIUM: chunk: do not rely on small trash by default for expressions
authorWilly Tarreau <w@1wt.eu>
Wed, 3 Jun 2026 12:00:31 +0000 (14:00 +0200)
committerWilly Tarreau <w@1wt.eu>
Wed, 3 Jun 2026 12:45:54 +0000 (14:45 +0200)
commitb79419026209276ae34ebf2b3330f8e6b57b1aa6
treec743a6704a2c3181f409c6d276b6665627a3676f
parentbf4878226e68a45e1daa7ebe397bfb68f44b8634
BUG/MEDIUM: chunk: do not rely on small trash by default for expressions

There's a corner case with get_trash_chunk_sz() combined with the use
of small bufs: if some incoming data is going to be inflated by a
converter in a non-predictable way (say url_enc etc) then there are
two possibilities:
  - either we try to allocate a size that corresponds to the data, but
    we risk to allocate a small buf to convert a 900B chunk, that will
    now fail if it contains too many non-printable chars;
  - or we try to allocate 3x the size to be conservative, but without
    large bufs we'd fail to transcode any chunk larger than 5.3kB, even
    if it contains only printable chars.

The approach should definitely be refined and it is not 100% reliable
for now. Better temporarily ignore the small buffers for these particular
cases where the savings are not relevant, and see how to pass the knowledge
of the expected size ranges deeper down the API in 3.5. We may possibly rely
on the current trash size (instead of contents) or other mechanisms that
are yet to be specified. alloc_small_trash_chunk() gets the same change
BTW for the same reasons.

The comment for get_trash_chunk_sz() was updated to restate the importance
of being conservative when requesting a size.

No backport is needed.
include/haproxy/chunk.h
src/chunk.c