Hi all, there is an issue with error handling as well, the result of an expression evaluation that causes error can be hardly determined, for example:
@rr.uri tries to parse the RR HF, and get the URI part of it, but it returns an error if the RR HF is missing from the request, because the parsing fails: if (@rr.uri) is false, which is correct. if ([EMAIL PROTECTED]) is also false, which is strange. The error is captured, and eval_expr() exists before negating the result. if (@rr.uri || 1) is also false, because nothing after @rr.uri is checked. The problem exists with AVPs as well: $second = 2; if ($second != "foo") is false, which means 2=="foo". The reason is the same as above, the string cannot be converted to integer, thus, the evaluator returns error. None of the above expressions should result error in my opinion, they could simply return true or false instead. What do you think? Thanks, Miklos On 04/11/2008 04:01 PM, Miklos Tirpak wrote: > Hi Michal, > > On 04/10/2008 06:55 PM, Michal Matyska wrote: >> Hi, >> >> I was meditating about the same issue, but related to select testing - >> see SER-353. In my oppinion (a!=b) should result the same as !(a==b). >> >> It is easy to achieve that every != will return true when either left or >> right (or both) parts are not existing - e.g AVP not found, or >> run_select function returns 1. I can provide the patch, it is held in my >> mercurial queue. > > the modifications in route.c are easy, I am almost ready with them. But > as I understood your bug report, you would like to differentiate not > existing, and empty select results, so the existence of a parameter > without a value could be verified for example: > > if (@whatever) is true if the select exists regardless of its value, > even with empty string (returns false with empty string currently) > > if (@whatever == "") is true if the select exists, and its value is > empty string. > > So one should use if (@whatever && (@whatever != "")) expression to > verify that the select exists with a non-empty value. Is that right? > > I makes the script a bit more complicated, but gives more feature, and > it is more precise in my opinion, so I like it. > > And the same modification should be done with AVPs as well, I mean the > value of the AVP should not be checked in case of NO_OP. > > > So the above fix is easy, but lots of core select functions return 0 > with empty string instead if 1 when run_select is called. Do you have a > patch for this? > >> BUT, this must be then accepted in ALL the scripts!!! E.g. if (@to.tag! >> ="") now will be TRUE for every request (because to tag is not present, >> or if present it must have non-empty value (RFC MUST)). > > Indeed, we will have to check the scripts. > >> >> >> The other possibility is to change the script comparison to accept the >> premise, that missing AVP or select yields empty string; which has >> different possible drawback - two non-existent AVP will be trated as >> equal. > > That sounds like a hack for me. > > Miklos > >> >> >> Michal >> >> >> Miklos Tirpak píše v Čt 10. 04. 2008 v 13:21 +0200: >>> Hi all, >>> >>> I am wondering whether the != operator was designed to work the >>> following way with AVPs: >>> >>> ($myavp != "myvalue") is true only if $myavp exists, and its value is >>> not equal to "myvalue". If the AVP does not exist, the expression is false. >>> >>> That means, (!($myavp == "myvalue")) and ($myavp != "myvalue") may be >>> evaluated differently, the former is true if the AVP is missing. Is it a >>> bug or a feature? >>> >>> I also wonder whether the script writers know about this, for example >>> there was a security hole in ser-oob script because of it: I was able to >>> fake any sip uri (which was not provisioned) in the from HF of >>> non-register request, and the authentication was successful. >>> >>> Thanks, >>> Miklos >>> _______________________________________________ >>> Serdev mailing list >>> [email protected] >>> http://lists.iptel.org/mailman/listinfo/serdev > _______________________________________________ > Serdev mailing list > [email protected] > http://lists.iptel.org/mailman/listinfo/serdev _______________________________________________ Serdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/serdev
