IMHO,<br><br>I wouldn't "equalize" non-existent parameter with empty string. There are header parameters (maddr,rport,isfocus) which may not have value and someone (who knows?) might need to check for them. I would just not forbid this option from the config file...
<br><br>I would just use the @ and !@ uses for detecting presence or absence of attributes and letting the == to check for the value once you know it exists. It "complicates" a little bit config file but makes it clearer and I think easier to debug.
<br><br>So, for me it's fine changing example config files and documenting it.<br><br>my 0.02,<br>Samuel<br><br><div><span class="gmail_quote">2007/6/8, Michal Matyska <<a href="mailto:michal@iptel.org">michal@iptel.org
</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Samuel,<br><br>yes it is related to. The resolution of SER-263 was wrong and every test
<br>like if (@select=="") has returned false, even the return value of<br>the select was empty string.<br><br>But, there is another problem I see in the config (including the example<br>script)...<br><br>There is difference between the (@select) test and (@select!="") one.
<br>The latter returns false, if the select framework returns N/A value<br>(e.g. non present header/parameter).<br><br>Intended behaviour was: @X is @route[1].params.lr in this example<br>(as the tag must have value if present rfc3261
19.3)<br><br>lr parameter test result<br>not present @X false<br> !@X true<br> @X=="" FALSE*<br> @X!="" FALSE*<br><br><br>lr @X true
<br> !@X false<br> @X=="" true<br> @X!="" false<br><br>lr=123 @X true<br> !@X false<br> @X=="" false
<br> @X!="" true<br><br><br>As I see the from the example ser.cfg, the tests are done in the<br>(@to.tag=="") way, which won't work if the to.tag would return either<br>N/A or the tag value. But it seems it returns the empty string even if
<br>not present, because it was previously working.<br><br>So I ask the community (especially TB potential members) do we want to<br>take care about the select N/A value differently, or shall we make it<br>equal to empty string?
<br><br>Note, that if the answer is yes, it will be very hard to differentiate<br>between parameter not present and parameter without value - well the lr<br>parameter is handled internally, but what others?<br><br>If the anwser is no, keep special N/A value handling, the select must be
<br>reviewed together with the ser.cfg, because (@to.tag=="") will be false<br>for every tag (because it must have value).<br><br>Michal<br><br>On Čt, 2007-06-07 at 13:56 +0200, samuel wrote:<br>> Michal,<br>
><br>> I've just post a question to users' list about not properly detecting<br>> @to.tag=="".<br>><br>> Is this bug related to it??<br>><br>> Thanks,<br>> Samuel.<br>><br>> 2007/6/7, Michal Matyska (JIRA) <
<a href="mailto:tracker@iptel.org">tracker@iptel.org</a>>:<br>> [ <a href="http://tracker.iptel.org/browse/SER-263?page=all">http://tracker.iptel.org/browse/SER-263?page=all</a> ]<br>><br>> Michal Matyska reopened SER-263:
<br>> --------------------------------<br>><br>><br>> The way it is now resolved is wrong. If the select returns<br>> empty string the script test if (@select=="") is false.
<br>><br>> > Using @select=~ "regexp" causes segmentation fault<br>> > --------------------------------------------------<br>> ><br>> > Key: SER-263
<br>> > URL: <a href="http://tracker.iptel.org/browse/SER-263">http://tracker.iptel.org/browse/SER-263</a><br>> > Project: SER<br>> > Issue Type: Bug
<br>> > Components: core, Selects<br>> > Affects Versions: 2.0, Ipteldorf<br>> > Environment: CVS head<br>> > Reporter: Michal Matyska
<br>> > Assigned To: Michal Matyska<br>> > Priority: Minor<br>> > Fix For: 2.0, Ipteldorf<br>> ><br>> ><br>> > If the result of the select is empty string or it is
<br>> STR_STATIC_INIT ( e.g. @uri.type) the prepatation of left<br>> operand (putting \0 behind the string) causes segmentation<br>> fault .<br>> > Program received signal SIGSEGV, Segmentation fault.
<br>> > comp_str (op=11, left=0xbfad27a4, rtype=5, r=0x81932b0,<br>> msg=0x81a1034) at route.c:668<br>> > 668 left->s[left->len]='\0';<br>>
<br>> --<br>> This message is automatically generated by JIRA.<br>> -<br>> If you think it was sent incorrectly contact one of the<br>> administrators:<br>>
<a href="http://tracker.iptel.org/secure/Administrators.jspa">http://tracker.iptel.org/secure/Administrators.jspa</a><br>> -<br>> For more information on JIRA, see:<br>> <a href="http://www.atlassian.com/software/jira">
http://www.atlassian.com/software/jira</a><br>><br>><br>> _______________________________________________<br>> Serdev mailing list<br>> <a href="mailto:Serdev@lists.iptel.org">Serdev@lists.iptel.org
</a><br>> <a href="http://lists.iptel.org/mailman/listinfo/serdev">http://lists.iptel.org/mailman/listinfo/serdev</a><br>><br>> _______________________________________________<br>> Serdev mailing list<br>
> <a href="mailto:Serdev@lists.iptel.org">Serdev@lists.iptel.org</a><br>> <a href="http://lists.iptel.org/mailman/listinfo/serdev">http://lists.iptel.org/mailman/listinfo/serdev</a><br><br></blockquote></div><br>