[reSIProcate] ParseBuffer::assertNotEof() ?

[Daniel Pocock]

Byron Campen wrote:

>     That is not valid syntax, no. However, it would make sense to  
> interpret this as the case where there is no tag parameter, and if  
> this is something that a TU cannot live with, then it can be rejected  
> there. Any objections?
>
I'm still seeing this behaviour in the latest code from SVN.

Does anyone object if I patch this to allow the tag= nothing syntax, or 
is there another preferred solution?

> Best regards,
> Byron Campen
>
>>
>> Looking at my own case below, is the packet with an empty `tag='
>> parameter valid?
>>
>> To: "Booth2" <sip:11 at sip.callshop.lvdx.com>;tag=
>>
>> Line 28 of DataParameter.cxx calls pb.assertNotEof(); - could the
>> following be done safely:
>>
>> if(pb.eof()) {
>>   mValue = Data("");
>>   return;
>> }
>>
>> or is there some other code that depends on the parameter having a  
>> value?
>>
>>
>> Byron Campen wrote:
>>
>>>     This sounds like a bug in dum. If an exception due to a parse
>>> failure is making it out of dum, then it is very likely the stack has
>>> leaked a TransactionState. If the exception is not caught in the
>>> appropriate place, not only is the SipMessage leaked, but there is no
>>> way to respond to it, meaning the TransactionState will never get
>>> cleaned up either (the stack waits indefinitely for the TU to  
>>> respond).
>>>
>>>     Unfortunately, there are many such bugs, because a lot of the
>>> code  was written before we transitioned to a lazy-parser, and the
>>> code was  never fixed. The upshot is that calling something like
>>> msg.header (h_HeaderName).someAccessor() will probably be what
>>> triggers the  parse of the header, and if that header is malformed,
>>> kaboom!
>>>
>>>     Fixing all the instances of this will take some time. I tried my
>>> best to clear up any errors of this type that existed in the stack
>>> (and I think I've gotten them all). I think that, at this point, it
>>> would make sense to add bool LazyParser::isWellFormed(), so we can
>>> check whether the header is well-formed in an exception-safe manner.
>>> This will make fixing the existing code a little easier. And for
>>> those who are writing new code, keep this in mind!
>>>
>>>     Now, I added a bandage for this problem that people can use in
>>> the  meantime. As a configure option, you can set PEDANTIC_STACK to
>>> true,  which cause the stack to do a full parse of SipMessages on
>>> receipt.  If a problem is discovered, it will be rejected  immediately.
>>> (ie, no  potential for a parse to fail later down the line, since
>>> everything  is already parsed) This is an expensive solution, but at
>>> least you  have the option.
>>>
>>> Best regards,
>>> Byron Campen
>>>
>>>>
>>>>
>>>> Occasionally, my application is receiving a packet which causes
>>>> assertNotEof() to throw an exception.
>>>>
>>>> How is this exception meant to be dealt with?  Am I intended to
>>>> catch it
>>>> with a try { } catch { } block around dum->process()?  Or should  this
>>>> exception be caught and handled (presumably by discarding the  packet)
>>>> within the stack?
>>>>
>>>> Here is the content of pb when the exception is thrown, the code in
>>>> DataParameter.cxx suggests the empty ;tag= is the fault:
>>>>
>>>> (gdb) print pb
>>>> $1 = (class resip::ParseBuffer &) @0xbfffe114: {
>>>>   static Whitespace = 0xb7ac4264 " \t\r\n",
>>>>   static ParamTerm = 0xb7ac4261 ";?",
>>>>   mBuff = 0x809dd4a "\"Booth2\"
>>>> <sip:11 at sip.callshop.lvdx.com>;tag=\r\nTo:
>>>> <sip:11 at sip.callshop.lvdx.com>;tag=\r\nContact:
>>>> <sip:11 at 83.146.x.x:5070>\r\nSupported: replaces\r\nProxy-  
>>>> Authorization:
>>>> Digest username=\"11\", realm=\"sip."..., mPosition = 0x809dd76 "\r
>>>> \nTo:
>>>> <sip:11 at sip.callshop.lvdx.com>;tag=\r\nContact:
>>>> <sip:11 at 83.146.x.x:5070>\r\nSupported: replaces\r\nProxy-  
>>>> Authorization:
>>>> Digest username=\"11\", realm=\"sip.callshop.lvdx.com\",   
>>>> algorithm=MD5,
>>>> uri=\"sip:"...,
>>>>   mEnd = 0x809dd76 "\r\nTo:
>>>> <sip:11 at sip.callshop.lvdx.com>;tag=\r\nContact:
>>>> <sip:11 at 83.146.x.x:5070>\r\nSupported: replaces\r\nProxy-  
>>>> Authorization:
>>>> Digest username=\"11\", realm=\"sip.callshop.lvdx.com\",   
>>>> algorithm=MD5,
>>>> uri=\"sip:"...,
>>>>   mErrorContext = @0xb7dc5c18}
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Daniel
>>>> _______________________________________________
>>>> resiprocate-devel mailing list
>>>> resiprocate-devel at list.sipfoundry.org
>>>> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>>>
>>>
>>>
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel at list.sipfoundry.org
>> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
>