tree bb6f4ab2d0f13a27c0bdcec7fbb59c731703639f
parent 88fca377546267d24ab23cb7f7d2e0eef9d71ee6
author Tim Duesterhus <duesterhus@woltlab.com> 1624021768 +0200
committer Christopher Faulet <cfaulet@haproxy.com> 1624456238 +0200

BUG/MINOR: cache: Correctly handle existing-but-empty 'accept-encoding' header

RFC 7231#5.3.4 makes a difference between a completely missing
'accept-encoding' header and an 'accept-encoding' header without any values.

This case was already correctly handled by accident, because an empty accept
encoding does not match any known encoding. However this resulted in the
'other' encoding being added to the bitmap. Usually this also succeeds in
serving cached responses, because the cached response likely has no
'content-encoding', thus matching the identity case instead of not serving the
response, due to the 'other' encoding. But it's technically not 100% correct.

Fix this by special-casing 'accept-encoding' values with a length of zero and
extend the test to check that an empty accept-encoding is correctly handled.
Due to the reasons given above the test also passes without the change in
cache.c.

Vary support was added in HAProxy 2.4. This fix should be backported to 2.4+.

(cherry picked from commit 3bc6af417d10e0f5c46f2997be919e14c689ab9c)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>