[asterisk-dev] [Code Review] SIP URI comparison test (plus some bug fixes)

[Rod Dorman]

On Thursday, July 22, 2010, 04:11:33, Kevin P. Fleming wrote:
> On 07/22/2010 08:58 AM, Olle E. Johansson wrote:
>> 21 jul 2010 kl. 16.56 skrev Rod Dorman:
>>> On Wednesday, July 21, 2010, 04:18:43, Kevin P. Fleming wrote:
>>>> On 07/21/2010 10:00 AM, Olle E. Johansson wrote:
>>>>> 20 jul 2010 kl. 15.15 skrev Simon Perreault:
>>>>>> /trunk/channels/sip/reqresp_parser.c
>>>>>> <https://reviewboard.asterisk.org/r/792/#comment5354>
>>>>>>   There's a subtle but important bug here: glibc's strcasecmp() is locale-dependent. SIP URI domains are limited to the ASCII character set. So we want ASCII-based case-insensitive comparison, not something that depends on the current locale.
>>>>>>   This could be solved by using strcasecmp_l() and passing the "C" locale (I think). Or just roll your own ASCII-based strcasecmp().
>>>>>
>>>>> That is a huge issue and possibly affects many different parts of asterisk.
>>>>> While writing the bug report I forgot to mention that the string comparision of IP also affects IPv4.
>>>>> 192.02.68.01 == 192.02.68.1
>>>>> 192.2.068.1 != 192.2.68.1
>>>>>
>>>>> The zero prefix indicates that the group is written in octal notation...
>>>
>>>> Are you sure about that? The ABNF that Mark already posted shows that
>>>> each group is limited to three digits, and three digits is not adequate
>>>> to allow for the range 0-255 to be expressed on octal, only in decimal.
>>>
>>> Not only that, in RFC 3986 "Uniform Resource Identifier (URI): Generic
>>> Syntax" under section "7.4 Rare IP Address Formats" it explicitly states
>>>    These additional IP address formats are not allowed in the URI
>>>    syntax due to differences between platform implementations.
>>>
>> 
>> Right. That's the theory. Then you have what happens out there in the wild... 
>> 
>> The new draft points out in very detail that you should compare the ip address in binary. Period.
>
> I don't think that was the point he was making; his point was that the
> conversion from text format to binary format should *always* interpret
> the digit strings as decimal,

Yes, that is what I was was trying to point out.

> regardless of whether any digit group starts with a zero digit or not.

If I'm reading the BNF correctly the definition of dec-octet does not
allow a leading 0 other than when it is a single 0.



-- 
rodd at polylogics.com     "The avalanche has already started, it is too
Rod Dorman              late for the pebbles to vote." - Ambassador Kosh