Run <if> value by ts_search:subst/2

[tisba]

This PR will run the value of <if> by ts_search:subst/2 to make it work with variables as well.

For example, if you need to compare a variable against another variable that you've extracted from a previous request, you can now do that.

Example:

<request>
  <dyn_variable name="extracted_token" re="X-CSRF-Token: (https?://.*)&#13;"/>
  <http url="http://example.com/login" method="GET" version="1.1">
  </http>
</request>

<!-- make some more request -->

<request>
  <dyn_variable name="current_token" re="X-CSRF-Token: (https?://.*)&#13;"/>
  <http url="http://example.com/basket" method="GET" version="1.1">
  </http>
</request>


<!-- abort current client in case tokens do not match and you cannot proceed -->

<if var="current_token" neq="%%_extracted_token%%">
  <abort type="session"/>
</if>

Fixes #168

[tisba]

I first thought about adding a flag to enable the substitution (like with <request>). But then I thought that this is quite counter intuitive.

Another option would be to a new/alternative attribute beside the literal "value".

The current solution feels the most natural too me though.

What do you think, @nniclausse?

[tisba]

ping @nniclausse

[nniclausse]

maybe we can add a subst flag during the xml parsing, if we detect the %%xxx%% pattern ?

if we don't do that, every use of an 'if' will call ts_search:subst even if we don't need substitutions.

[tisba]

I like that idea! I was first thinking about subst="true" but since we should be able to detect that automatically that's probably way better.

I'll try to give this a shot.

[tisba]

Can you take another look, @nniclausse? I'm not sure if this approach is sufficient. I'm simply peeking into the value and if I see %% I enable substitution.

[tisba]

Could you take another look, @nniclausse?

[nniclausse]

we should use re:run(Value, "%%.+%%") instead if think

[tisba]

Okay. I thought string:str because that's recommended for performance reasons, but since we are only parsing the configuration, that should not be a issue to begin with.

I'll change this.

Do you have anything else on the new approach?