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/sample_fetches/vars.vtc

84 lines
3.0 KiB
Plaintext
Raw Normal View History

REGTESTS: add a basic reg-test for some "set-var" commands This reg-test tests "set-var" in the global section, with some overlapping variables and using a few samples and converters, then at the TCP and HTTP levels using proc/sess/req variables.
2021-03-26 13:03:57 +00:00
varnishtest "Test a few set-var() in global, tcp and http rule sets, at different scopes"
MEDIUM: vars: add a new "set-var-fmt" action The set-var() action is convenient because it preserves the input type but it's a pain to deal with when trying to concatenate values. The most recurring example is when it's needed to build a variable composed of the source address and the source port. Usually it ends up like this: tcp-request session set-var(sess.port) src_port tcp-request session set-var(sess.addr) src,concat(":",sess.port) This is even worse when trying to aggregate multiple fields from stick-table data for example. Due to this a lot of users instead abuse headers from HTTP rules: http-request set-header(x-addr) %[src]:%[src_port] But this requires some careful cleanups to make sure they won't leak, and it's significantly more expensive to deal with. And generally speaking it's not clean. Plus it must be performed for each and every request, which is expensive for this common case of ip+port that doesn't change for the whole session. This patch addresses this limitation by implementing a new "set-var-fmt" action which performs the same work as "set-var" but takes a format string in argument instead of an expression. This way it becomes pretty simple to just write: tcp-request session set-var-fmt(sess.addr) %[src]:%[src_port] It is usable in all rulesets that already support the "set-var" action. It is not yet implemented for the global "set-var" directive (which already takes a string) and the CLI's "set var" command, which would definitely benefit from it but currently uses its own parser and engine, thus it must be reworked. The doc and regtests were updated.
2021-09-02 19:00:38 +00:00
feature cmd "$HAPROXY_PROGRAM -cc 'version_atleast(2.5-dev5)'"
REGTESTS: add a basic reg-test for some "set-var" commands This reg-test tests "set-var" in the global section, with some overlapping variables and using a few samples and converters, then at the TCP and HTTP levels using proc/sess/req variables.
2021-03-26 13:03:57 +00:00
feature ignore_unknown_macro
haproxy h1 -conf {
global
set-var proc.int12 int(12)
set-var proc.int5 str(60),div(proc.int12)
MEDIUM: vars: add a new "set-var-fmt" action The set-var() action is convenient because it preserves the input type but it's a pain to deal with when trying to concatenate values. The most recurring example is when it's needed to build a variable composed of the source address and the source port. Usually it ends up like this: tcp-request session set-var(sess.port) src_port tcp-request session set-var(sess.addr) src,concat(":",sess.port) This is even worse when trying to aggregate multiple fields from stick-table data for example. Due to this a lot of users instead abuse headers from HTTP rules: http-request set-header(x-addr) %[src]:%[src_port] But this requires some careful cleanups to make sure they won't leak, and it's significantly more expensive to deal with. And generally speaking it's not clean. Plus it must be performed for each and every request, which is expensive for this common case of ip+port that doesn't change for the whole session. This patch addresses this limitation by implementing a new "set-var-fmt" action which performs the same work as "set-var" but takes a format string in argument instead of an expression. This way it becomes pretty simple to just write: tcp-request session set-var-fmt(sess.addr) %[src]:%[src_port] It is usable in all rulesets that already support the "set-var" action. It is not yet implemented for the global "set-var" directive (which already takes a string) and the CLI's "set var" command, which would definitely benefit from it but currently uses its own parser and engine, thus it must be reworked. The doc and regtests were updated.
2021-09-02 19:00:38 +00:00
set-var proc.str1 str("this is")
set-var proc.str2 str("a string")
set-var proc.str var(proc.str1)
MINOR: vars: add a "set-var-fmt" directive to the global section Just like the set-var-fmt action for tcp/http rules, the set-var-fmt directive in global sections allows to pre-set process-wide variables using a format string instead of a sample expression. This is often more convenient when it is required to concatenate multiple fields, or when emitting just one word.
2021-09-03 07:02:47 +00:00
set-var-fmt proc.str "%[var(proc.str)] a string"
REGTESTS: add a basic reg-test for some "set-var" commands This reg-test tests "set-var" in the global section, with some overlapping variables and using a few samples and converters, then at the TCP and HTTP levels using proc/sess/req variables.
2021-03-26 13:03:57 +00:00
set-var proc.uuid uuid()
defaults
mode http
timeout connect 1s
timeout client 1s
timeout server 1s
frontend fe1
bind "fd@${fe1}"
MEDIUM: vars: add a new "set-var-fmt" action The set-var() action is convenient because it preserves the input type but it's a pain to deal with when trying to concatenate values. The most recurring example is when it's needed to build a variable composed of the source address and the source port. Usually it ends up like this: tcp-request session set-var(sess.port) src_port tcp-request session set-var(sess.addr) src,concat(":",sess.port) This is even worse when trying to aggregate multiple fields from stick-table data for example. Due to this a lot of users instead abuse headers from HTTP rules: http-request set-header(x-addr) %[src]:%[src_port] But this requires some careful cleanups to make sure they won't leak, and it's significantly more expensive to deal with. And generally speaking it's not clean. Plus it must be performed for each and every request, which is expensive for this common case of ip+port that doesn't change for the whole session. This patch addresses this limitation by implementing a new "set-var-fmt" action which performs the same work as "set-var" but takes a format string in argument instead of an expression. This way it becomes pretty simple to just write: tcp-request session set-var-fmt(sess.addr) %[src]:%[src_port] It is usable in all rulesets that already support the "set-var" action. It is not yet implemented for the global "set-var" directive (which already takes a string) and the CLI's "set var" command, which would definitely benefit from it but currently uses its own parser and engine, thus it must be reworked. The doc and regtests were updated.
2021-09-02 19:00:38 +00:00
tcp-request session set-var-fmt(sess.str3) "%[var(proc.str1)] %[var(proc.str2)]"
REGTESTS: add a basic reg-test for some "set-var" commands This reg-test tests "set-var" in the global section, with some overlapping variables and using a few samples and converters, then at the TCP and HTTP levels using proc/sess/req variables.
2021-03-26 13:03:57 +00:00
tcp-request session set-var(sess.int5) var(proc.int5)
tcp-request session set-var(proc.int5) var(proc.int5),add(sess.int5) ## proc. becomes 10
MEDIUM: vars: add a new "set-var-fmt" action The set-var() action is convenient because it preserves the input type but it's a pain to deal with when trying to concatenate values. The most recurring example is when it's needed to build a variable composed of the source address and the source port. Usually it ends up like this: tcp-request session set-var(sess.port) src_port tcp-request session set-var(sess.addr) src,concat(":",sess.port) This is even worse when trying to aggregate multiple fields from stick-table data for example. Due to this a lot of users instead abuse headers from HTTP rules: http-request set-header(x-addr) %[src]:%[src_port] But this requires some careful cleanups to make sure they won't leak, and it's significantly more expensive to deal with. And generally speaking it's not clean. Plus it must be performed for each and every request, which is expensive for this common case of ip+port that doesn't change for the whole session. This patch addresses this limitation by implementing a new "set-var-fmt" action which performs the same work as "set-var" but takes a format string in argument instead of an expression. This way it becomes pretty simple to just write: tcp-request session set-var-fmt(sess.addr) %[src]:%[src_port] It is usable in all rulesets that already support the "set-var" action. It is not yet implemented for the global "set-var" directive (which already takes a string) and the CLI's "set var" command, which would definitely benefit from it but currently uses its own parser and engine, thus it must be reworked. The doc and regtests were updated.
2021-09-02 19:00:38 +00:00
tcp-request content set-var-fmt(req.str4) "%[var(sess.str3),regsub(is a,is also a)]"
http-request set-var-fmt(txn.str5) "%[var(req.str4)]"
REGTESTS: add a basic reg-test for some "set-var" commands This reg-test tests "set-var" in the global section, with some overlapping variables and using a few samples and converters, then at the TCP and HTTP levels using proc/sess/req variables.
2021-03-26 13:03:57 +00:00
http-request set-var(req.int5) var(sess.int5)
http-request set-var(sess.int5) var(sess.int5),add(req.int5) ## sess. becomes 10 first time, then 15...
MEDIUM: vars: add a new "set-var-fmt" action The set-var() action is convenient because it preserves the input type but it's a pain to deal with when trying to concatenate values. The most recurring example is when it's needed to build a variable composed of the source address and the source port. Usually it ends up like this: tcp-request session set-var(sess.port) src_port tcp-request session set-var(sess.addr) src,concat(":",sess.port) This is even worse when trying to aggregate multiple fields from stick-table data for example. Due to this a lot of users instead abuse headers from HTTP rules: http-request set-header(x-addr) %[src]:%[src_port] But this requires some careful cleanups to make sure they won't leak, and it's significantly more expensive to deal with. And generally speaking it's not clean. Plus it must be performed for each and every request, which is expensive for this common case of ip+port that doesn't change for the whole session. This patch addresses this limitation by implementing a new "set-var-fmt" action which performs the same work as "set-var" but takes a format string in argument instead of an expression. This way it becomes pretty simple to just write: tcp-request session set-var-fmt(sess.addr) %[src]:%[src_port] It is usable in all rulesets that already support the "set-var" action. It is not yet implemented for the global "set-var" directive (which already takes a string) and the CLI's "set var" command, which would definitely benefit from it but currently uses its own parser and engine, thus it must be reworked. The doc and regtests were updated.
2021-09-02 19:00:38 +00:00
http-request return status 200 hdr x-var "proc=%[var(proc.int5)] sess=%[var(sess.int5)] req=%[var(req.int5)] str=%[var(proc.str)] str5=%[var(txn.str5)] uuid=%[var(proc.uuid)]"
REGTESTS: add a basic reg-test for some "set-var" commands This reg-test tests "set-var" in the global section, with some overlapping variables and using a few samples and converters, then at the TCP and HTTP levels using proc/sess/req variables.
2021-03-26 13:03:57 +00:00
} -start
MINOR: vars/cli: add a "get var" CLI command to retrieve global variables Process-wide variables can now be displayed from the CLI using "get var" followed by the variable name. They must all start with "proc." otherwise they will not be found. The output is very similar to the one of the debug converter, with a type and value being reported for the embedded sample. This command is limited to clients with the level "operator" or higher, since it can possibly expose traffic-related data.
2021-03-26 13:51:31 +00:00
haproxy h1 -cli {
send "get var proc.int5"
expect ~ "^proc.int5: type=sint value=<5>$"
}
REGTESTS: add a basic reg-test for some "set-var" commands This reg-test tests "set-var" in the global section, with some overlapping variables and using a few samples and converters, then at the TCP and HTTP levels using proc/sess/req variables.
2021-03-26 13:03:57 +00:00
client c1 -connect ${h1_fe1_sock} {
txreq -req GET -url /req1_1
rxresp
expect resp.status == 200
MEDIUM: vars: add a new "set-var-fmt" action The set-var() action is convenient because it preserves the input type but it's a pain to deal with when trying to concatenate values. The most recurring example is when it's needed to build a variable composed of the source address and the source port. Usually it ends up like this: tcp-request session set-var(sess.port) src_port tcp-request session set-var(sess.addr) src,concat(":",sess.port) This is even worse when trying to aggregate multiple fields from stick-table data for example. Due to this a lot of users instead abuse headers from HTTP rules: http-request set-header(x-addr) %[src]:%[src_port] But this requires some careful cleanups to make sure they won't leak, and it's significantly more expensive to deal with. And generally speaking it's not clean. Plus it must be performed for each and every request, which is expensive for this common case of ip+port that doesn't change for the whole session. This patch addresses this limitation by implementing a new "set-var-fmt" action which performs the same work as "set-var" but takes a format string in argument instead of an expression. This way it becomes pretty simple to just write: tcp-request session set-var-fmt(sess.addr) %[src]:%[src_port] It is usable in all rulesets that already support the "set-var" action. It is not yet implemented for the global "set-var" directive (which already takes a string) and the CLI's "set var" command, which would definitely benefit from it but currently uses its own parser and engine, thus it must be reworked. The doc and regtests were updated.
2021-09-02 19:00:38 +00:00
expect resp.http.x-var ~ "proc=10 sess=10 req=5 str=this is a string str5=this is also a string uuid=[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*"
REGTESTS: add a basic reg-test for some "set-var" commands This reg-test tests "set-var" in the global section, with some overlapping variables and using a few samples and converters, then at the TCP and HTTP levels using proc/sess/req variables.
2021-03-26 13:03:57 +00:00
txreq -req GET -url /req1_2
rxresp
expect resp.status == 200
MEDIUM: vars: add a new "set-var-fmt" action The set-var() action is convenient because it preserves the input type but it's a pain to deal with when trying to concatenate values. The most recurring example is when it's needed to build a variable composed of the source address and the source port. Usually it ends up like this: tcp-request session set-var(sess.port) src_port tcp-request session set-var(sess.addr) src,concat(":",sess.port) This is even worse when trying to aggregate multiple fields from stick-table data for example. Due to this a lot of users instead abuse headers from HTTP rules: http-request set-header(x-addr) %[src]:%[src_port] But this requires some careful cleanups to make sure they won't leak, and it's significantly more expensive to deal with. And generally speaking it's not clean. Plus it must be performed for each and every request, which is expensive for this common case of ip+port that doesn't change for the whole session. This patch addresses this limitation by implementing a new "set-var-fmt" action which performs the same work as "set-var" but takes a format string in argument instead of an expression. This way it becomes pretty simple to just write: tcp-request session set-var-fmt(sess.addr) %[src]:%[src_port] It is usable in all rulesets that already support the "set-var" action. It is not yet implemented for the global "set-var" directive (which already takes a string) and the CLI's "set var" command, which would definitely benefit from it but currently uses its own parser and engine, thus it must be reworked. The doc and regtests were updated.
2021-09-02 19:00:38 +00:00
expect resp.http.x-var ~ "proc=10 sess=20 req=10 str=this is a string str5=this is also a string uuid=[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*"
REGTESTS: add a basic reg-test for some "set-var" commands This reg-test tests "set-var" in the global section, with some overlapping variables and using a few samples and converters, then at the TCP and HTTP levels using proc/sess/req variables.
2021-03-26 13:03:57 +00:00
} -run
MINOR: vars/cli: add a "get var" CLI command to retrieve global variables Process-wide variables can now be displayed from the CLI using "get var" followed by the variable name. They must all start with "proc." otherwise they will not be found. The output is very similar to the one of the debug converter, with a type and value being reported for the embedded sample. This command is limited to clients with the level "operator" or higher, since it can possibly expose traffic-related data.
2021-03-26 13:51:31 +00:00
haproxy h1 -cli {
send "get var proc.int5"
expect ~ "^proc.int5: type=sint value=<10>$"
}
REGTESTS: add a basic reg-test for some "set-var" commands This reg-test tests "set-var" in the global section, with some overlapping variables and using a few samples and converters, then at the TCP and HTTP levels using proc/sess/req variables.
2021-03-26 13:03:57 +00:00
client c2 -connect ${h1_fe1_sock} {
txreq -req GET -url /req2_1
rxresp
expect resp.status == 200
MEDIUM: vars: add a new "set-var-fmt" action The set-var() action is convenient because it preserves the input type but it's a pain to deal with when trying to concatenate values. The most recurring example is when it's needed to build a variable composed of the source address and the source port. Usually it ends up like this: tcp-request session set-var(sess.port) src_port tcp-request session set-var(sess.addr) src,concat(":",sess.port) This is even worse when trying to aggregate multiple fields from stick-table data for example. Due to this a lot of users instead abuse headers from HTTP rules: http-request set-header(x-addr) %[src]:%[src_port] But this requires some careful cleanups to make sure they won't leak, and it's significantly more expensive to deal with. And generally speaking it's not clean. Plus it must be performed for each and every request, which is expensive for this common case of ip+port that doesn't change for the whole session. This patch addresses this limitation by implementing a new "set-var-fmt" action which performs the same work as "set-var" but takes a format string in argument instead of an expression. This way it becomes pretty simple to just write: tcp-request session set-var-fmt(sess.addr) %[src]:%[src_port] It is usable in all rulesets that already support the "set-var" action. It is not yet implemented for the global "set-var" directive (which already takes a string) and the CLI's "set var" command, which would definitely benefit from it but currently uses its own parser and engine, thus it must be reworked. The doc and regtests were updated.
2021-09-02 19:00:38 +00:00
expect resp.http.x-var ~ "proc=20 sess=20 req=10 str=this is a string str5=this is also a string uuid=[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*"
REGTESTS: add a basic reg-test for some "set-var" commands This reg-test tests "set-var" in the global section, with some overlapping variables and using a few samples and converters, then at the TCP and HTTP levels using proc/sess/req variables.
2021-03-26 13:03:57 +00:00
txreq -req GET -url /req2_2
rxresp
expect resp.status == 200
MEDIUM: vars: add a new "set-var-fmt" action The set-var() action is convenient because it preserves the input type but it's a pain to deal with when trying to concatenate values. The most recurring example is when it's needed to build a variable composed of the source address and the source port. Usually it ends up like this: tcp-request session set-var(sess.port) src_port tcp-request session set-var(sess.addr) src,concat(":",sess.port) This is even worse when trying to aggregate multiple fields from stick-table data for example. Due to this a lot of users instead abuse headers from HTTP rules: http-request set-header(x-addr) %[src]:%[src_port] But this requires some careful cleanups to make sure they won't leak, and it's significantly more expensive to deal with. And generally speaking it's not clean. Plus it must be performed for each and every request, which is expensive for this common case of ip+port that doesn't change for the whole session. This patch addresses this limitation by implementing a new "set-var-fmt" action which performs the same work as "set-var" but takes a format string in argument instead of an expression. This way it becomes pretty simple to just write: tcp-request session set-var-fmt(sess.addr) %[src]:%[src_port] It is usable in all rulesets that already support the "set-var" action. It is not yet implemented for the global "set-var" directive (which already takes a string) and the CLI's "set var" command, which would definitely benefit from it but currently uses its own parser and engine, thus it must be reworked. The doc and regtests were updated.
2021-09-02 19:00:38 +00:00
expect resp.http.x-var ~ "proc=20 sess=40 req=20 str=this is a string str5=this is also a string uuid=[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*"
REGTESTS: add a basic reg-test for some "set-var" commands This reg-test tests "set-var" in the global section, with some overlapping variables and using a few samples and converters, then at the TCP and HTTP levels using proc/sess/req variables.
2021-03-26 13:03:57 +00:00
} -run
MINOR: vars/cli: add a "get var" CLI command to retrieve global variables Process-wide variables can now be displayed from the CLI using "get var" followed by the variable name. They must all start with "proc." otherwise they will not be found. The output is very similar to the one of the debug converter, with a type and value being reported for the embedded sample. This command is limited to clients with the level "operator" or higher, since it can possibly expose traffic-related data.
2021-03-26 13:51:31 +00:00
haproxy h1 -cli {
send "get var proc.int5"
expect ~ "^proc.int5: type=sint value=<20>$"
}
MEDIUM: cli: add a new experimental "set var" command set var <name> <expression> Allows to set or overwrite the process-wide variable 'name' with the result of expression <expression>. Only process-wide variables may be used, so the name must begin with 'proc.' otherwise no variable will be set. The <expression> may only involve "internal" sample fetch keywords and converters even though the most likely useful ones will be str('something') or int(). Note that the command line parser doesn't know about quotes, so any space in the expression must be preceeded by a backslash. This command requires levels "operator" or "admin". This command is only supported on a CLI connection running in experimental mode (see "experimental-mode on"). Just like for "set-var" in the global section, the command uses a temporary dummy proxy to create a temporary "set-var(name)" rule to assign the value. The reg test was updated to verify that an updated global variable is properly reflected in subsequent HTTP responses.
2021-03-26 14:19:50 +00:00
haproxy h1 -cli {
send "experimental-mode on; set var proc.str str(updated)"
expect ~ .*
}
client c3 -connect ${h1_fe1_sock} {
txreq -req GET -url /req3_1
rxresp
expect resp.status == 200
MEDIUM: vars: add a new "set-var-fmt" action The set-var() action is convenient because it preserves the input type but it's a pain to deal with when trying to concatenate values. The most recurring example is when it's needed to build a variable composed of the source address and the source port. Usually it ends up like this: tcp-request session set-var(sess.port) src_port tcp-request session set-var(sess.addr) src,concat(":",sess.port) This is even worse when trying to aggregate multiple fields from stick-table data for example. Due to this a lot of users instead abuse headers from HTTP rules: http-request set-header(x-addr) %[src]:%[src_port] But this requires some careful cleanups to make sure they won't leak, and it's significantly more expensive to deal with. And generally speaking it's not clean. Plus it must be performed for each and every request, which is expensive for this common case of ip+port that doesn't change for the whole session. This patch addresses this limitation by implementing a new "set-var-fmt" action which performs the same work as "set-var" but takes a format string in argument instead of an expression. This way it becomes pretty simple to just write: tcp-request session set-var-fmt(sess.addr) %[src]:%[src_port] It is usable in all rulesets that already support the "set-var" action. It is not yet implemented for the global "set-var" directive (which already takes a string) and the CLI's "set var" command, which would definitely benefit from it but currently uses its own parser and engine, thus it must be reworked. The doc and regtests were updated.
2021-09-02 19:00:38 +00:00
expect resp.http.x-var ~ "proc=40 sess=40 req=20 str=updated str5=this is also a string uuid=[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*"
MEDIUM: cli: add a new experimental "set var" command set var <name> <expression> Allows to set or overwrite the process-wide variable 'name' with the result of expression <expression>. Only process-wide variables may be used, so the name must begin with 'proc.' otherwise no variable will be set. The <expression> may only involve "internal" sample fetch keywords and converters even though the most likely useful ones will be str('something') or int(). Note that the command line parser doesn't know about quotes, so any space in the expression must be preceeded by a backslash. This command requires levels "operator" or "admin". This command is only supported on a CLI connection running in experimental mode (see "experimental-mode on"). Just like for "set-var" in the global section, the command uses a temporary dummy proxy to create a temporary "set-var(name)" rule to assign the value. The reg test was updated to verify that an updated global variable is properly reflected in subsequent HTTP responses.
2021-03-26 14:19:50 +00:00
} -run