RepoMirrors/haproxy
1
0
Fork 0
mirror of http://git.haproxy.org/git/haproxy.git/ synced 2024-12-30 08:32:05 +00:00
Code Issues Packages Projects Releases Wiki Activity
9e3c8d5512
haproxy/reg-tests/lua/set_var.vtc

84 lines
Plaintext
Raw Normal View History

MINOR: lua: Make `set_var()` and `unset_var()` return success This patch makes `set_var()` and `unset_var()` return a boolean indicating success.
2020-05-19 11:49:41 +00:00
varnishtest "Lua: set_var"
REGTESTS: Require the version 2.2 to execute lua/set_var This script depends on LUA changes introduced in HAProxy 2.2 and not backported.
2020-05-26 09:11:23 +00:00
#REQUIRE_VERSION=2.2
MINOR: lua: Make `set_var()` and `unset_var()` return success This patch makes `set_var()` and `unset_var()` return a boolean indicating success.
2020-05-19 11:49:41 +00:00
#REQUIRE_OPTIONS=LUA
feature ignore_unknown_macro
haproxy h1 -conf {
global
REGTESTS: disable inter-thread idle connection sharing on sensitive tests Some regtests involve multiple requests from multiple clients, which can be dispatched as multiple requests to a server. It turns out that the idle connection sharing works so well that very quickly few connections are used, and regularly some of the remaining idle server connections time out at the moment they were going to be reused, causing those random "HTTP header incomplete" traces in the logs that make them fail often. In the end this is only an artefact of the test environment. And indeed, some tests like normalize-uri which perform a lot of reuse fail very often, about 20-30% of the times in the CI, and 100% of the time in local when running 1000 tests in a row. Others like ubase64, sample_fetches or vary_* fail less often but still a lot in tests. This patch addresses this by adding "tune.idle-pool.shared off" to all tests which have at least twice as many requests as clients. It proves very effective as no single error happens on normalize-uri anymore after 10000 tests. Also 100 full runs of all tests yield no error anymore. One test is tricky, http_abortonclose, it used to fail ~10 times per 1000 runs and with this workaround still fails once every 1000 runs. But the test is complex and there's a warning in it mentioning a possible issue when run in parallel due to a port reuse.
2021-05-09 12:41:41 +00:00
# WT: limit false-positives causing "HTTP header incomplete" due to
# idle server connections being randomly used and randomly expiring
# under us.
tune.idle-pool.shared off
global
MINOR: lua: Make `set_var()` and `unset_var()` return success This patch makes `set_var()` and `unset_var()` return a boolean indicating success.
2020-05-19 11:49:41 +00:00
lua-load ${testdir}/set_var.lua
frontend fe1
mode http
bind "fd@${fe1}"
http-request use-service lua.set_var
MEDIUM: lua: Add `ifexist` parameter to `set_var` As discussed in GitHub issue #624 Lua scripts should not use variables that are never going to be read, because the memory for variable names is never going to be freed. Add an optional `ifexist` parameter to the `set_var` function that allows a Lua developer to set variables that are going to be ignored if the variable name was not used elsewhere before. Usually this mean that there is no `var()` sample fetch for the variable in question within the configuration.
2020-05-19 11:49:42 +00:00
frontend fe2
mode http
bind "fd@${fe2}"
MEDIUM: vars: replace the global name index with a hash The global table of known variables names can only grow and was designed for static names that are registered at boot. Nowadays it's possible to set dynamic variable names from Lua or from the CLI, which causes a real problem that was partially addressed in 2.2 with commit 4e172c93f ("MEDIUM: lua: Add `ifexist` parameter to `set_var`"). Please see github issue #624 for more context. This patch simplifies all this by removing the need for a central registry of known names, and storing 64-bit hashes instead. This is highly sufficient given the low number of variables in each context. The hash is calculated using XXH64() which is bijective over the 64-bit space thus is guaranteed collision-free for 1..8 chars. Above that the risk remains around 1/2^64 per extra 8 chars so in practice this is highly sufficient for our usage. A random seed is used at boot to seed the hash so that it's not attackable from Lua for example. There's one particular nit though. The "ifexist" hack mentioned above is now limited to variables of scope "proc" only, and will only match variables that were already created or declared, but will now verify the scope as well. This may affect some bogus Lua scripts and SPOE agents which used to accidentally work because a similarly named variable used to exist in a different scope. These ones may need to be fixed to comply with the doc. Now we can sum up the situation as this one: - ephemeral variables (scopes sess, txn, req, res) will always be usable, regardless of any prior declaration. This effectively addresses the most problematic change from the commit above that in order to work well could have required some script auditing ; - process-wide variables (scope proc) that are mentioned in the configuration, referenced in a "register-var-names" SPOE directive, or created via "set-var" in the global section or the CLI, are permanent and will always accept to be set, with or without the "ifexist" restriction (SPOE uses this internally as well). - process-wide variables (scope proc) that are only created via a set-var() tcp/http action, via Lua's set_var() calls, or via an SPOE with the "force-set-var" directive), will not be permanent but will always accept to be replaced once they are created, even if "ifexist" is present - process-wide variables (scope proc) that do not exist will only support being created via the set-var() tcp/http action, Lua's set_var() calls without "ifexist", or an SPOE declared with "force-set-var". This means that non-proc variables do not care about "ifexist" nor prior declaration, and that using "ifexist" should most often be reliable in Lua and that SPOE should most often work without any prior declaration. It may be doable to turn "ifexist" to 1 by default in Lua to further ease the transition. Note: regtests were adjusted. Cc: Tim Düsterhus <tim@bastelstu.be>
2021-08-31 06:51:02 +00:00
# just make sure the variable exists
http-request set-header Dummy %[var(proc.fe2_foo)]
MEDIUM: lua: Add `ifexist` parameter to `set_var` As discussed in GitHub issue #624 Lua scripts should not use variables that are never going to be read, because the memory for variable names is never going to be freed. Add an optional `ifexist` parameter to the `set_var` function that allows a Lua developer to set variables that are going to be ignored if the variable name was not used elsewhere before. Usually this mean that there is no `var()` sample fetch for the variable in question within the configuration.
2020-05-19 11:49:42 +00:00
http-request use-service lua.set_var_ifexist
MINOR: lua: Make `set_var()` and `unset_var()` return success This patch makes `set_var()` and `unset_var()` return a boolean indicating success.
2020-05-19 11:49:41 +00:00
} -start
client c0 -connect ${h1_fe1_sock} {
MEDIUM: vars: replace the global name index with a hash The global table of known variables names can only grow and was designed for static names that are registered at boot. Nowadays it's possible to set dynamic variable names from Lua or from the CLI, which causes a real problem that was partially addressed in 2.2 with commit 4e172c93f ("MEDIUM: lua: Add `ifexist` parameter to `set_var`"). Please see github issue #624 for more context. This patch simplifies all this by removing the need for a central registry of known names, and storing 64-bit hashes instead. This is highly sufficient given the low number of variables in each context. The hash is calculated using XXH64() which is bijective over the 64-bit space thus is guaranteed collision-free for 1..8 chars. Above that the risk remains around 1/2^64 per extra 8 chars so in practice this is highly sufficient for our usage. A random seed is used at boot to seed the hash so that it's not attackable from Lua for example. There's one particular nit though. The "ifexist" hack mentioned above is now limited to variables of scope "proc" only, and will only match variables that were already created or declared, but will now verify the scope as well. This may affect some bogus Lua scripts and SPOE agents which used to accidentally work because a similarly named variable used to exist in a different scope. These ones may need to be fixed to comply with the doc. Now we can sum up the situation as this one: - ephemeral variables (scopes sess, txn, req, res) will always be usable, regardless of any prior declaration. This effectively addresses the most problematic change from the commit above that in order to work well could have required some script auditing ; - process-wide variables (scope proc) that are mentioned in the configuration, referenced in a "register-var-names" SPOE directive, or created via "set-var" in the global section or the CLI, are permanent and will always accept to be set, with or without the "ifexist" restriction (SPOE uses this internally as well). - process-wide variables (scope proc) that are only created via a set-var() tcp/http action, via Lua's set_var() calls, or via an SPOE with the "force-set-var" directive), will not be permanent but will always accept to be replaced once they are created, even if "ifexist" is present - process-wide variables (scope proc) that do not exist will only support being created via the set-var() tcp/http action, Lua's set_var() calls without "ifexist", or an SPOE declared with "force-set-var". This means that non-proc variables do not care about "ifexist" nor prior declaration, and that using "ifexist" should most often be reliable in Lua and that SPOE should most often work without any prior declaration. It may be doable to turn "ifexist" to 1 by default in Lua to further ease the transition. Note: regtests were adjusted. Cc: Tim Düsterhus <tim@bastelstu.be>
2021-08-31 06:51:02 +00:00
# create var
MINOR: lua: Make `set_var()` and `unset_var()` return success This patch makes `set_var()` and `unset_var()` return a boolean indicating success.
2020-05-19 11:49:41 +00:00
txreq -url "/" \
MEDIUM: lua: Add `ifexist` parameter to `set_var` As discussed in GitHub issue #624 Lua scripts should not use variables that are never going to be read, because the memory for variable names is never going to be freed. Add an optional `ifexist` parameter to the `set_var` function that allows a Lua developer to set variables that are going to be ignored if the variable name was not used elsewhere before. Usually this mean that there is no `var()` sample fetch for the variable in question within the configuration.
2020-05-19 11:49:42 +00:00
-hdr "Var: txn.fe1_foo"
MINOR: lua: Make `set_var()` and `unset_var()` return success This patch makes `set_var()` and `unset_var()` return a boolean indicating success.
2020-05-19 11:49:41 +00:00
rxresp
expect resp.status == 202
expect resp.http.echo == "value"
MEDIUM: vars: replace the global name index with a hash The global table of known variables names can only grow and was designed for static names that are registered at boot. Nowadays it's possible to set dynamic variable names from Lua or from the CLI, which causes a real problem that was partially addressed in 2.2 with commit 4e172c93f ("MEDIUM: lua: Add `ifexist` parameter to `set_var`"). Please see github issue #624 for more context. This patch simplifies all this by removing the need for a central registry of known names, and storing 64-bit hashes instead. This is highly sufficient given the low number of variables in each context. The hash is calculated using XXH64() which is bijective over the 64-bit space thus is guaranteed collision-free for 1..8 chars. Above that the risk remains around 1/2^64 per extra 8 chars so in practice this is highly sufficient for our usage. A random seed is used at boot to seed the hash so that it's not attackable from Lua for example. There's one particular nit though. The "ifexist" hack mentioned above is now limited to variables of scope "proc" only, and will only match variables that were already created or declared, but will now verify the scope as well. This may affect some bogus Lua scripts and SPOE agents which used to accidentally work because a similarly named variable used to exist in a different scope. These ones may need to be fixed to comply with the doc. Now we can sum up the situation as this one: - ephemeral variables (scopes sess, txn, req, res) will always be usable, regardless of any prior declaration. This effectively addresses the most problematic change from the commit above that in order to work well could have required some script auditing ; - process-wide variables (scope proc) that are mentioned in the configuration, referenced in a "register-var-names" SPOE directive, or created via "set-var" in the global section or the CLI, are permanent and will always accept to be set, with or without the "ifexist" restriction (SPOE uses this internally as well). - process-wide variables (scope proc) that are only created via a set-var() tcp/http action, via Lua's set_var() calls, or via an SPOE with the "force-set-var" directive), will not be permanent but will always accept to be replaced once they are created, even if "ifexist" is present - process-wide variables (scope proc) that do not exist will only support being created via the set-var() tcp/http action, Lua's set_var() calls without "ifexist", or an SPOE declared with "force-set-var". This means that non-proc variables do not care about "ifexist" nor prior declaration, and that using "ifexist" should most often be reliable in Lua and that SPOE should most often work without any prior declaration. It may be doable to turn "ifexist" to 1 by default in Lua to further ease the transition. Note: regtests were adjusted. Cc: Tim Düsterhus <tim@bastelstu.be>
2021-08-31 06:51:02 +00:00
# rewrite var
txreq -url "/" \
-hdr "Var: txn.fe1_foo"
rxresp
expect resp.status == 202
expect resp.http.echo == "value"
# create var under scope "proc"
txreq -url "/" \
-hdr "Var: proc.fe1_foo"
rxresp
expect resp.status == 202
expect resp.http.echo == "value"
# fail to create bad scope
MINOR: lua: Make `set_var()` and `unset_var()` return success This patch makes `set_var()` and `unset_var()` return a boolean indicating success.
2020-05-19 11:49:41 +00:00
txreq -url "/" \
-hdr "Var: invalid.var"
rxresp
expect resp.status == 400
expect resp.http.echo == "(nil)"
} -run
MEDIUM: lua: Add `ifexist` parameter to `set_var` As discussed in GitHub issue #624 Lua scripts should not use variables that are never going to be read, because the memory for variable names is never going to be freed. Add an optional `ifexist` parameter to the `set_var` function that allows a Lua developer to set variables that are going to be ignored if the variable name was not used elsewhere before. Usually this mean that there is no `var()` sample fetch for the variable in question within the configuration.
2020-05-19 11:49:42 +00:00
client c1 -connect ${h1_fe2_sock} {
MEDIUM: vars: replace the global name index with a hash The global table of known variables names can only grow and was designed for static names that are registered at boot. Nowadays it's possible to set dynamic variable names from Lua or from the CLI, which causes a real problem that was partially addressed in 2.2 with commit 4e172c93f ("MEDIUM: lua: Add `ifexist` parameter to `set_var`"). Please see github issue #624 for more context. This patch simplifies all this by removing the need for a central registry of known names, and storing 64-bit hashes instead. This is highly sufficient given the low number of variables in each context. The hash is calculated using XXH64() which is bijective over the 64-bit space thus is guaranteed collision-free for 1..8 chars. Above that the risk remains around 1/2^64 per extra 8 chars so in practice this is highly sufficient for our usage. A random seed is used at boot to seed the hash so that it's not attackable from Lua for example. There's one particular nit though. The "ifexist" hack mentioned above is now limited to variables of scope "proc" only, and will only match variables that were already created or declared, but will now verify the scope as well. This may affect some bogus Lua scripts and SPOE agents which used to accidentally work because a similarly named variable used to exist in a different scope. These ones may need to be fixed to comply with the doc. Now we can sum up the situation as this one: - ephemeral variables (scopes sess, txn, req, res) will always be usable, regardless of any prior declaration. This effectively addresses the most problematic change from the commit above that in order to work well could have required some script auditing ; - process-wide variables (scope proc) that are mentioned in the configuration, referenced in a "register-var-names" SPOE directive, or created via "set-var" in the global section or the CLI, are permanent and will always accept to be set, with or without the "ifexist" restriction (SPOE uses this internally as well). - process-wide variables (scope proc) that are only created via a set-var() tcp/http action, via Lua's set_var() calls, or via an SPOE with the "force-set-var" directive), will not be permanent but will always accept to be replaced once they are created, even if "ifexist" is present - process-wide variables (scope proc) that do not exist will only support being created via the set-var() tcp/http action, Lua's set_var() calls without "ifexist", or an SPOE declared with "force-set-var". This means that non-proc variables do not care about "ifexist" nor prior declaration, and that using "ifexist" should most often be reliable in Lua and that SPOE should most often work without any prior declaration. It may be doable to turn "ifexist" to 1 by default in Lua to further ease the transition. Note: regtests were adjusted. Cc: Tim Düsterhus <tim@bastelstu.be>
2021-08-31 06:51:02 +00:00
# this one exists in the conf, it must succeed
MEDIUM: lua: Add `ifexist` parameter to `set_var` As discussed in GitHub issue #624 Lua scripts should not use variables that are never going to be read, because the memory for variable names is never going to be freed. Add an optional `ifexist` parameter to the `set_var` function that allows a Lua developer to set variables that are going to be ignored if the variable name was not used elsewhere before. Usually this mean that there is no `var()` sample fetch for the variable in question within the configuration.
2020-05-19 11:49:42 +00:00
txreq -url "/" \
MEDIUM: vars: replace the global name index with a hash The global table of known variables names can only grow and was designed for static names that are registered at boot. Nowadays it's possible to set dynamic variable names from Lua or from the CLI, which causes a real problem that was partially addressed in 2.2 with commit 4e172c93f ("MEDIUM: lua: Add `ifexist` parameter to `set_var`"). Please see github issue #624 for more context. This patch simplifies all this by removing the need for a central registry of known names, and storing 64-bit hashes instead. This is highly sufficient given the low number of variables in each context. The hash is calculated using XXH64() which is bijective over the 64-bit space thus is guaranteed collision-free for 1..8 chars. Above that the risk remains around 1/2^64 per extra 8 chars so in practice this is highly sufficient for our usage. A random seed is used at boot to seed the hash so that it's not attackable from Lua for example. There's one particular nit though. The "ifexist" hack mentioned above is now limited to variables of scope "proc" only, and will only match variables that were already created or declared, but will now verify the scope as well. This may affect some bogus Lua scripts and SPOE agents which used to accidentally work because a similarly named variable used to exist in a different scope. These ones may need to be fixed to comply with the doc. Now we can sum up the situation as this one: - ephemeral variables (scopes sess, txn, req, res) will always be usable, regardless of any prior declaration. This effectively addresses the most problematic change from the commit above that in order to work well could have required some script auditing ; - process-wide variables (scope proc) that are mentioned in the configuration, referenced in a "register-var-names" SPOE directive, or created via "set-var" in the global section or the CLI, are permanent and will always accept to be set, with or without the "ifexist" restriction (SPOE uses this internally as well). - process-wide variables (scope proc) that are only created via a set-var() tcp/http action, via Lua's set_var() calls, or via an SPOE with the "force-set-var" directive), will not be permanent but will always accept to be replaced once they are created, even if "ifexist" is present - process-wide variables (scope proc) that do not exist will only support being created via the set-var() tcp/http action, Lua's set_var() calls without "ifexist", or an SPOE declared with "force-set-var". This means that non-proc variables do not care about "ifexist" nor prior declaration, and that using "ifexist" should most often be reliable in Lua and that SPOE should most often work without any prior declaration. It may be doable to turn "ifexist" to 1 by default in Lua to further ease the transition. Note: regtests were adjusted. Cc: Tim Düsterhus <tim@bastelstu.be>
2021-08-31 06:51:02 +00:00
-hdr "Var: proc.fe2_foo"
MEDIUM: lua: Add `ifexist` parameter to `set_var` As discussed in GitHub issue #624 Lua scripts should not use variables that are never going to be read, because the memory for variable names is never going to be freed. Add an optional `ifexist` parameter to the `set_var` function that allows a Lua developer to set variables that are going to be ignored if the variable name was not used elsewhere before. Usually this mean that there is no `var()` sample fetch for the variable in question within the configuration.
2020-05-19 11:49:42 +00:00
rxresp
expect resp.status == 202
expect resp.http.echo == "value"
MEDIUM: vars: replace the global name index with a hash The global table of known variables names can only grow and was designed for static names that are registered at boot. Nowadays it's possible to set dynamic variable names from Lua or from the CLI, which causes a real problem that was partially addressed in 2.2 with commit 4e172c93f ("MEDIUM: lua: Add `ifexist` parameter to `set_var`"). Please see github issue #624 for more context. This patch simplifies all this by removing the need for a central registry of known names, and storing 64-bit hashes instead. This is highly sufficient given the low number of variables in each context. The hash is calculated using XXH64() which is bijective over the 64-bit space thus is guaranteed collision-free for 1..8 chars. Above that the risk remains around 1/2^64 per extra 8 chars so in practice this is highly sufficient for our usage. A random seed is used at boot to seed the hash so that it's not attackable from Lua for example. There's one particular nit though. The "ifexist" hack mentioned above is now limited to variables of scope "proc" only, and will only match variables that were already created or declared, but will now verify the scope as well. This may affect some bogus Lua scripts and SPOE agents which used to accidentally work because a similarly named variable used to exist in a different scope. These ones may need to be fixed to comply with the doc. Now we can sum up the situation as this one: - ephemeral variables (scopes sess, txn, req, res) will always be usable, regardless of any prior declaration. This effectively addresses the most problematic change from the commit above that in order to work well could have required some script auditing ; - process-wide variables (scope proc) that are mentioned in the configuration, referenced in a "register-var-names" SPOE directive, or created via "set-var" in the global section or the CLI, are permanent and will always accept to be set, with or without the "ifexist" restriction (SPOE uses this internally as well). - process-wide variables (scope proc) that are only created via a set-var() tcp/http action, via Lua's set_var() calls, or via an SPOE with the "force-set-var" directive), will not be permanent but will always accept to be replaced once they are created, even if "ifexist" is present - process-wide variables (scope proc) that do not exist will only support being created via the set-var() tcp/http action, Lua's set_var() calls without "ifexist", or an SPOE declared with "force-set-var". This means that non-proc variables do not care about "ifexist" nor prior declaration, and that using "ifexist" should most often be reliable in Lua and that SPOE should most often work without any prior declaration. It may be doable to turn "ifexist" to 1 by default in Lua to further ease the transition. Note: regtests were adjusted. Cc: Tim Düsterhus <tim@bastelstu.be>
2021-08-31 06:51:02 +00:00
# this one does not exist in the conf, it must fail
MEDIUM: lua: Add `ifexist` parameter to `set_var` As discussed in GitHub issue #624 Lua scripts should not use variables that are never going to be read, because the memory for variable names is never going to be freed. Add an optional `ifexist` parameter to the `set_var` function that allows a Lua developer to set variables that are going to be ignored if the variable name was not used elsewhere before. Usually this mean that there is no `var()` sample fetch for the variable in question within the configuration.
2020-05-19 11:49:42 +00:00
txreq -url "/" \
MEDIUM: vars: replace the global name index with a hash The global table of known variables names can only grow and was designed for static names that are registered at boot. Nowadays it's possible to set dynamic variable names from Lua or from the CLI, which causes a real problem that was partially addressed in 2.2 with commit 4e172c93f ("MEDIUM: lua: Add `ifexist` parameter to `set_var`"). Please see github issue #624 for more context. This patch simplifies all this by removing the need for a central registry of known names, and storing 64-bit hashes instead. This is highly sufficient given the low number of variables in each context. The hash is calculated using XXH64() which is bijective over the 64-bit space thus is guaranteed collision-free for 1..8 chars. Above that the risk remains around 1/2^64 per extra 8 chars so in practice this is highly sufficient for our usage. A random seed is used at boot to seed the hash so that it's not attackable from Lua for example. There's one particular nit though. The "ifexist" hack mentioned above is now limited to variables of scope "proc" only, and will only match variables that were already created or declared, but will now verify the scope as well. This may affect some bogus Lua scripts and SPOE agents which used to accidentally work because a similarly named variable used to exist in a different scope. These ones may need to be fixed to comply with the doc. Now we can sum up the situation as this one: - ephemeral variables (scopes sess, txn, req, res) will always be usable, regardless of any prior declaration. This effectively addresses the most problematic change from the commit above that in order to work well could have required some script auditing ; - process-wide variables (scope proc) that are mentioned in the configuration, referenced in a "register-var-names" SPOE directive, or created via "set-var" in the global section or the CLI, are permanent and will always accept to be set, with or without the "ifexist" restriction (SPOE uses this internally as well). - process-wide variables (scope proc) that are only created via a set-var() tcp/http action, via Lua's set_var() calls, or via an SPOE with the "force-set-var" directive), will not be permanent but will always accept to be replaced once they are created, even if "ifexist" is present - process-wide variables (scope proc) that do not exist will only support being created via the set-var() tcp/http action, Lua's set_var() calls without "ifexist", or an SPOE declared with "force-set-var". This means that non-proc variables do not care about "ifexist" nor prior declaration, and that using "ifexist" should most often be reliable in Lua and that SPOE should most often work without any prior declaration. It may be doable to turn "ifexist" to 1 by default in Lua to further ease the transition. Note: regtests were adjusted. Cc: Tim Düsterhus <tim@bastelstu.be>
2021-08-31 06:51:02 +00:00
-hdr "Var: proc.fe2_bar"
MEDIUM: lua: Add `ifexist` parameter to `set_var` As discussed in GitHub issue #624 Lua scripts should not use variables that are never going to be read, because the memory for variable names is never going to be freed. Add an optional `ifexist` parameter to the `set_var` function that allows a Lua developer to set variables that are going to be ignored if the variable name was not used elsewhere before. Usually this mean that there is no `var()` sample fetch for the variable in question within the configuration.
2020-05-19 11:49:42 +00:00
rxresp
expect resp.status == 400
expect resp.http.echo == "(nil)"
MEDIUM: vars: replace the global name index with a hash The global table of known variables names can only grow and was designed for static names that are registered at boot. Nowadays it's possible to set dynamic variable names from Lua or from the CLI, which causes a real problem that was partially addressed in 2.2 with commit 4e172c93f ("MEDIUM: lua: Add `ifexist` parameter to `set_var`"). Please see github issue #624 for more context. This patch simplifies all this by removing the need for a central registry of known names, and storing 64-bit hashes instead. This is highly sufficient given the low number of variables in each context. The hash is calculated using XXH64() which is bijective over the 64-bit space thus is guaranteed collision-free for 1..8 chars. Above that the risk remains around 1/2^64 per extra 8 chars so in practice this is highly sufficient for our usage. A random seed is used at boot to seed the hash so that it's not attackable from Lua for example. There's one particular nit though. The "ifexist" hack mentioned above is now limited to variables of scope "proc" only, and will only match variables that were already created or declared, but will now verify the scope as well. This may affect some bogus Lua scripts and SPOE agents which used to accidentally work because a similarly named variable used to exist in a different scope. These ones may need to be fixed to comply with the doc. Now we can sum up the situation as this one: - ephemeral variables (scopes sess, txn, req, res) will always be usable, regardless of any prior declaration. This effectively addresses the most problematic change from the commit above that in order to work well could have required some script auditing ; - process-wide variables (scope proc) that are mentioned in the configuration, referenced in a "register-var-names" SPOE directive, or created via "set-var" in the global section or the CLI, are permanent and will always accept to be set, with or without the "ifexist" restriction (SPOE uses this internally as well). - process-wide variables (scope proc) that are only created via a set-var() tcp/http action, via Lua's set_var() calls, or via an SPOE with the "force-set-var" directive), will not be permanent but will always accept to be replaced once they are created, even if "ifexist" is present - process-wide variables (scope proc) that do not exist will only support being created via the set-var() tcp/http action, Lua's set_var() calls without "ifexist", or an SPOE declared with "force-set-var". This means that non-proc variables do not care about "ifexist" nor prior declaration, and that using "ifexist" should most often be reliable in Lua and that SPOE should most often work without any prior declaration. It may be doable to turn "ifexist" to 1 by default in Lua to further ease the transition. Note: regtests were adjusted. Cc: Tim Düsterhus <tim@bastelstu.be>
2021-08-31 06:51:02 +00:00
# this one is under txn, it must succeed
txreq -url "/" \
-hdr "Var: txn.fe2_foo"
rxresp
expect resp.status == 202
expect resp.http.echo == "value"
MEDIUM: lua: Add `ifexist` parameter to `set_var` As discussed in GitHub issue #624 Lua scripts should not use variables that are never going to be read, because the memory for variable names is never going to be freed. Add an optional `ifexist` parameter to the `set_var` function that allows a Lua developer to set variables that are going to be ignored if the variable name was not used elsewhere before. Usually this mean that there is no `var()` sample fetch for the variable in question within the configuration.
2020-05-19 11:49:42 +00:00
} -run
Reference in New Issue Copy Permalink