Re: 6.0.2 to 6.1.1 Migration issue: malformed From header no longer reachable in routing script
Henning Westerholt via sr-users <[email protected]> Fri, 13 Mar 2026 09:38:51 +0000
| Newsgroups | gmane.comp.voip.ser |
|---|---|
| Message-ID | <AS8PR07MB722164B1016099413B3A2C55BF45A@AS8PR07MB7221.eurprd07.prod.outlook.com> |
Hello, Just an idea, maybe you can use the sanity module instead, which also should return a 400 in generic header parser errors. Cheers, Henning > -----Original Message----- > From: m.cazzola--- via sr-users <[email protected]> > Sent: Mittwoch, 11. März 2026 14:02 > To: [email protected] > Cc: [email protected] > Subject: [SR-Users] 6.0.2 to 6.1.1 Migration issue: malformed From header no > longer reachable in routing script > > Hello, > > I am writing regarding a behaviour change between Kamailio 6.0.2 and 6.1.1 > that is causing one of our system tests to fail. > > The test sends intentionally malformed SIP INVITE requests and expects a 400 > response. The failing cases involve malformed From headers (e.g. an empty > From). > > After reviewing the changelog and tracing the code, we believe the change was > introduced in commit cf1c796 (cherry-picked into 6.0.4), which reworks From > header parsing in get_hdr_field() to use the shared parse_to_body() function. > > As a result, a malformed From now causes parse_headers() to return an error > earlier in receive.c, before the message reaches the routing script. > > Previously, the From header parsing failure was caught deep enough in > execution for our sanity_check() call in the request route to detect and handle > it — sending back a 400 as RFC 3261 implies. > > Now, the failure happens before the routing script is reached. We have > attempted to intercept it in event_route[core:pre-routing] and > event_route[core:receive-parse-error], but to no avail. All of our other > malformed type messages (e.g. a bad Expires value or invalid RURI) work as > intended. > > Our questions are: > Is there any hook, event, or flag we could use to detect and respond to this > condition before the message is dropped? > If no config-level workaround exists, are there any other alternatives? > > Thank you in advance for your time. > > Best regards, > > Matteo Cazzola > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions -- sr- > [email protected] > To unsubscribe send an email to [email protected] > Important: keep the mailing list in the recipients, do not reply only to the > sender! __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected] To unsubscribe send an email to [email protected] Important: keep the mailing list in the recipients, do not reply only to the sender!