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

85 lines
3.2 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
MINOR: vars: make the vars() sample fetch function support a default value It is quite common to see in configurations constructions like the following one: http-request set-var(txn.bodylen) 0 http-request set-var(txn.bodylen) req.hdr(content-length) ... http-request set-header orig-len %[var(txn.bodylen)] The set-var() rules are almost always duplicated when manipulating integers or any other value that is mandatory along operations. This is a problem because it makes the configurations complicated to maintain and slower than needed. And it becomes even more complicated when several conditions may set the same variable because the risk of forgetting to initialize it or to accidentally reset it is high. This patch extends the var() sample fetch function to take an optional argument which contains a default value to be returned if the variable was not set. This way it becomes much simpler to use the variable, just set it where needed, and read it with a fall back to the default value: http-request set-var(txn.bodylen) req.hdr(content-length) ... http-request set-header orig-len %[var(txn.bodylen,0)] The default value is always passed as a string, thus it will experience a cast to the output type. It doesn't seem userful to complicate the configuration to pass an explicit type at this point. The vars.vtc regtest was updated accordingly.
2021-09-03 10:00:13 +00:00
# note below, str60 is purposely not defined so that the default is used
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.int12 int(12)
MINOR: vars: make the vars() sample fetch function support a default value It is quite common to see in configurations constructions like the following one: http-request set-var(txn.bodylen) 0 http-request set-var(txn.bodylen) req.hdr(content-length) ... http-request set-header orig-len %[var(txn.bodylen)] The set-var() rules are almost always duplicated when manipulating integers or any other value that is mandatory along operations. This is a problem because it makes the configurations complicated to maintain and slower than needed. And it becomes even more complicated when several conditions may set the same variable because the risk of forgetting to initialize it or to accidentally reset it is high. This patch extends the var() sample fetch function to take an optional argument which contains a default value to be returned if the variable was not set. This way it becomes much simpler to use the variable, just set it where needed, and read it with a fall back to the default value: http-request set-var(txn.bodylen) req.hdr(content-length) ... http-request set-header orig-len %[var(txn.bodylen,0)] The default value is always passed as a string, thus it will experience a cast to the output type. It doesn't seem userful to complicate the configuration to pass an explicit type at this point. The vars.vtc regtest was updated accordingly.
2021-09-03 10:00:13 +00:00
set-var proc.int5 var(proc.str60,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
REGTESTS: extend the default I/O timeouts and make them overridable With the CI occasionally slowing down, we're starting to see again some spurious failures despite the long 1-second timeouts. This reports false positives that are disturbing and doesn't provide as much value as this could. However at this delay it already becomes a pain for developers to wait for the tests to complete. This commit adds support for the new environment variable HAPROXY_TEST_TIMEOUT that will allow anyone to modify the connect, client and server timeouts. It was set to 5 seconds by default, which should be plenty for quite some time in the CI. All relevant values that were 200ms or above were replaced by this one. A few larger values were left as they are special. One test for the set-timeout action that used to rely on a fixed 1-sec value was extended to a fixed 5-sec, as the timeout is normally not reached, but it needs to be known to compare the old and new values.
2021-11-18 16:46:22 +00:00
timeout connect "${HAPROXY_TEST_TIMEOUT-5s}"
timeout client "${HAPROXY_TEST_TIMEOUT-5s}"
timeout server "${HAPROXY_TEST_TIMEOUT-5s}"
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
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 {
MEDIUM: vars: also support format strings in CLI's "set var" command Most often "set var" on the CLI is used to set a string, and using only expressions is not always convenient, particularly when trying to concatenate variables sur as host names and paths. Now the "set var" command supports an optional keyword before the value to indicate its type. "expr" takes an expression just like before this patch, and "fmt" a format string, making it work like the "set-var-fmt" actions. The VTC was updated to include a test on the format string.
2021-09-03 07:47:37 +00:00
send "experimental-mode on; set var proc.str str(updating); set var proc.str fmt %[var(proc.str),regsub(ing,ed)]"
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
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