[Serusers] [Serdev] [Tracker] Reopened: (SER-263) Using @select=~ "regexp" causes segmentation fault

[Jan Janak]

Michal Matyska wrote:
> Samuel,
> 
> 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
> script)...
> 
> 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[1].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
  lr="" imho.

  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[1].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
  meaning.

> 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).

      Jan.