RepoMirrors
/
haproxy
mirror of http://git.haproxy.org/git/haproxy.git/
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
haproxy/reg-tests/http-rules/map_ordering.vtc

47 lines
1.6 KiB
Plaintext
Raw Normal View History

MINOR: map: mapfile ordering also matters for tree-based match types Willy made me realize that tree-based matching may also suffer from out-of-order mapfile loading, as opposed to what's being said in b546bb6d ("BUG/MINOR: map: list-based matching potential ordering regression") and the associated REGTEST. Indeed, in case of duplicated keys, we want to be sure that only the key that was first seen in the file will be returned (as long as it is not removed). The above fix is still valid, and the list-based match regtest will also prevent regressions for tree-based match since mapfile loading logic is currently match-type agnostic. But let's clarify that by making both the code comment and the regtest more precise.
2024-01-11 09:31:04 +00:00
varnishtest "Ensure mapfile ordering is preserved when loading the file"
REGTESTS: add a test to ensure map-ordering is preserved As shown in "BUG/MINOR: map: list-based matching potential ordering regression", list-based matching types such as dom are affected by the order in which elements are loaded from the map. Since this is historical behavior and existing usages depend on it, we add a test to prevent future regressions.
2024-01-08 09:25:18 +00:00
feature cmd "$HAPROXY_PROGRAM -cc 'version_atleast(2.5-dev0)'"
feature ignore_unknown_macro
haproxy h1 -conf {
defaults
mode http
timeout connect "${HAPROXY_TEST_TIMEOUT-5s}"
timeout client "${HAPROXY_TEST_TIMEOUT-5s}"
timeout server "${HAPROXY_TEST_TIMEOUT-5s}"
frontend fe1
bind "fd@${fe1}"
# check list ordering using map_dom (list-based match)
http-request return hdr dom %[req.hdr(Host),lower,map_dom(${testdir}/map_ordering.map)] if { url_beg /dom }
MINOR: map: mapfile ordering also matters for tree-based match types Willy made me realize that tree-based matching may also suffer from out-of-order mapfile loading, as opposed to what's being said in b546bb6d ("BUG/MINOR: map: list-based matching potential ordering regression") and the associated REGTEST. Indeed, in case of duplicated keys, we want to be sure that only the key that was first seen in the file will be returned (as long as it is not removed). The above fix is still valid, and the list-based match regtest will also prevent regressions for tree-based match since mapfile loading logic is currently match-type agnostic. But let's clarify that by making both the code comment and the regtest more precise.
2024-01-11 09:31:04 +00:00
# check tree ordering using map_str (tree-based match) and duplicated keys
http-request return hdr str %[req.hdr(Host),lower,map_str(${testdir}/map_ordering.map)] if { url_beg /str }
REGTESTS: add a test to ensure map-ordering is preserved As shown in "BUG/MINOR: map: list-based matching potential ordering regression", list-based matching types such as dom are affected by the order in which elements are loaded from the map. Since this is historical behavior and existing usages depend on it, we add a test to prevent future regressions.
2024-01-08 09:25:18 +00:00
} -start
MINOR: map: mapfile ordering also matters for tree-based match types Willy made me realize that tree-based matching may also suffer from out-of-order mapfile loading, as opposed to what's being said in b546bb6d ("BUG/MINOR: map: list-based matching potential ordering regression") and the associated REGTEST. Indeed, in case of duplicated keys, we want to be sure that only the key that was first seen in the file will be returned (as long as it is not removed). The above fix is still valid, and the list-based match regtest will also prevent regressions for tree-based match since mapfile loading logic is currently match-type agnostic. But let's clarify that by making both the code comment and the regtest more precise.
2024-01-11 09:31:04 +00:00
# Check map ordering for list-based matching types
REGTESTS: add a test to ensure map-ordering is preserved As shown in "BUG/MINOR: map: list-based matching potential ordering regression", list-based matching types such as dom are affected by the order in which elements are loaded from the map. Since this is historical behavior and existing usages depend on it, we add a test to prevent future regressions.
2024-01-08 09:25:18 +00:00
client c1 -connect ${h1_fe1_sock} {
# first.domain.tld is above domain.tld so it should match first
txreq -url "/dom" -hdr "Host: first.domain.tld"
rxresp
expect resp.status == 200
expect resp.http.dom == "first"
# second.domain.tld is below domain.tld so domain.tld should match first
txreq -url "/dom" -hdr "Host: second.domain.tld"
rxresp
expect resp.status == 200
expect resp.http.dom == "domain"
} -run
MINOR: map: mapfile ordering also matters for tree-based match types Willy made me realize that tree-based matching may also suffer from out-of-order mapfile loading, as opposed to what's being said in b546bb6d ("BUG/MINOR: map: list-based matching potential ordering regression") and the associated REGTEST. Indeed, in case of duplicated keys, we want to be sure that only the key that was first seen in the file will be returned (as long as it is not removed). The above fix is still valid, and the list-based match regtest will also prevent regressions for tree-based match since mapfile loading logic is currently match-type agnostic. But let's clarify that by making both the code comment and the regtest more precise.
2024-01-11 09:31:04 +00:00
# Check map ordering for tree-based matching types (check that the matching
# key is the first one seen in the file)
client c2 -connect ${h1_fe1_sock} {
# first.domain.tld is first mapped to "first" in the mapfile
txreq -url "/str" -hdr "Host: first.domain.tld"
rxresp
expect resp.status == 200
expect resp.http.str == "first"
} -run