| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index |
On Aug 8, 2006, at 3:44 PM, Jason Fischl wrote:
On 8/8/06, Byron Campen <bcampen@xxxxxxxxxxxx> wrote:On Aug 8, 2006, at 3:32 PM, Jason Fischl wrote: > On 8/8/06, Byron Campen <bcampen@xxxxxxxxxxxx> wrote: >> Actually, this is a bad example; we end up parsing the topmost Via >> when we grab the transaction id. The point here is that really >> bizarre stuff can show up at the TU. >> > > We parse everything that is required in the transaction in the> Transport before the TransactionState object is created. The code is> all in Transport::basicCheck. The > > The items such as To, From, Call-ID are dialog-specific and are not > required in order to produce a failure response to a request. No, it doesn't. basicCheck() relies on Helper::validateMessage(), which just makes a bunch of calls to SipMessage::exists(). SipMessage::exists() doesn't parse anything.I don't think anything other than the Via and Request-Line need to be parsed in a request in order to be able to generate a response (or at least this should be the case). I'm not suggesting that there isn't a bug but I think we need to be careful here. The fact that exists returned true, indicates that the scanner(preparser) was able to identify a header that loosely corresponds to the correct thing. We know for sure that nothing will throw as a result of a parse error in the Transaction. Any parse exceptions will occur in the TU and can be caught there and handled appropriately. I think we just need a way to generate a failure response from a bad SipMessage. We know where to send it, we just need to send something back. My initial take on this is that it is better to send a 400 response than to drop it on the floor in these cases.
Ok, agreed. Feedback is good in these cases. So, do we want to try to change Helper::makeResponse() to be safe, or do we want a special- case function that assumes that nothing is right with the request, and just form as minimal a response as possible? (My initial instinct is to make makeResponse safe, just to keep the API clean, but this could make the code very ugly)
Best regards, Byron Campen
Attachment:
smime.p7s
Description: S/MIME cryptographic signature