[reSIProcate] ParseBuffer::assertNotEof() ?

[Daniel Pocock]

>
>
>>         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