[Serusers] [Serdev] [Tracker] Reopened: (SER-263) Using @select=~ "regexp" causes segmentation fault
jan at iptel.org
Fri Jun 8 11:27:52 CEST 2007
Michal Matyska wrote:
> yes it is related to. The resolution of SER-263 was wrong and every test
> like if (@select=="") has returned false, even the return value of
> the select was empty string.
> But, there is another problem I see in the config (including the example
> There is difference between the (@select) test and (@select!="") one.
> The latter returns false, if the select framework returns N/A value
> (e.g. non present header/parameter).
> Intended behaviour was: @X is @route.params.lr in this example
> (as the tag must have value if present rfc3261 19.3)
> lr parameter test result
> not present @X false
> !@X true
> @X=="" FALSE*
> @X!="" FALSE*
> lr @X true
> !@X false
> @X=="" true
> @X!="" false
Shouldn't @X=="" return false in this case? (the parameter has no
value, not even empty one). To make this true the parameter should be
IMHO if you specify a value to test in the expression then the
parameter must have a value for the test to succeed. If you do not
specify any value in the expression then the presence of the parameter
should be sufficient for the test to succeed.
> lr=123 @X true
> !@X false
> @X=="" false
> @X!="" true
The rest seems fine to me.
> As I see the from the example ser.cfg, the tests are done in the
> (@to.tag=="") way, which won't work if the to.tag would return either
> N/A or the tag value. But it seems it returns the empty string even if
> not present, because it was previously working.
As far as I can remember it used to work the way you describe (at
least I was using @route.params.lr in my configs to test for the
presence of the lr parameter some time ago.
> So I ask the community (especially TB potential members) do we want to
> take care about the select N/A value differently, or shall we make it
> equal to empty string?
No, we should not make it equal. We need to have a mechanism to test
for the presence of a parameter regardless its value and yet we need
to be able to test if a parameter is set to an empty string.
> Note, that if the answer is yes, it will be very hard to differentiate
> between parameter not present and parameter without value - well the lr
> parameter is handled internally, but what others?
In digest authentication this could be important. There the absence of
a parameter could change the way hash computations are done. The
presence of the same parameter, albeit with empty value has different
> If the anwser is no, keep special N/A value handling, the select must be
> reviewed together with the ser.cfg, because (@to.tag=="") will be false
> for every tag (because it must have value).
More information about the Serusers