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!