Added option to loosen message parsing to allow AVPs with empty/invalid payloads while defaulting to strict parsing #147
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I am working with equipments that can occasionally send slightly invalid messages, containing empty AVPs (the length is valid, but the "data" is empty).
This change aims to address this issue by adding an optional parameter in dictionaries to set whether the parsing of incoming messages should be strict or not (it is strict by default).
TODO
dict.NewParserFromLibrary
and it needs to be modified to setp.Strict = true
just likedict.NewParser
does.Example usage
How to get the parsing error?
When
Parser.Strict
is set tofalse
, the parsing error is accessible like so:Example error (shows the AVP stack, down the actual error, and it contains all the invalid AVPs, not just the first one):
Failed to decode one or more AVPs: {Service-Information(873): Grouped{SMS-Information(2000): Grouped{Recipient-SCCP-Address(2010): Not enough data to make an Address from byte[0] = []}}}