Re: [reSIProcate] ParseBuffer::assertNotEof() ?
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!
The above comment is not really correct. resip has had a lazy parser
since the beginning. Any application code that triggers parsing needs
to check for parse exceptions. In many cases, it should be possible to
put a single try/catch that handles ParseExceptions somewhere fairly
high up in a ThreadIf subclass main loop. I think we can safely put a
try/catch in DialogUsageManager::internalProcess that can handle lots
of these cases and automatically send a failure response when a parse
exception occurs as a result of an inbound sip request. This should
catch most of these issues.
In my case, the first attempt to parse the To: header is in a class
implementing ServerAuthManager::requiresChallenge()
The method can only return true or false, or propogate the exception
back to the caller.
Obviously, neither return value is applicable when a parse error occurs,
and in any case, the same parse error occurs later on when the request
is being looked at later in the chain.
Therefore, in callback methods like requiresChallenge(), should the
developer simply propogate the exception and let the stack deal with it?
Regards,
Daniel