[Non-conformance] Handling Unreapeatable Options

[bathooman]

Environment

• Build System: [Make]
• Operating System: [Linux]
• Branch: master

Problem Description

Upon receiving a CoAP message with an unrepeatable option, FreeCoAP fails to behave correctly.

Expected Behavior

According to RFC7252:

'''If a message includes an option with more occurrences than the option is defined for, each supernumerary option occurrence that appears subsequently in the message MUST be treated like an unrecognized option (see Section 5.4.1).'''

Section 5.4.1 states:

'''Options fall into one of two classes: "critical" or "elective". The difference between these is how an option unrecognized by an endpoint is handled:
o Upon reception, unrecognized options of class "elective" MUST be silently ignored.
o Unrecognized options of class "critical" that occur in a Confirmable request MUST cause the return of a 4.02 (Bad Option) response. This response SHOULD include a diagnostic payload describing the unrecognized option(s) (see Section 5.5.2).
o Unrecognized options of class "critical" that occur in a Confirmable response, or piggybacked in an Acknowledgement, MUST cause the response to be rejected (Section 4.2).
o Unrecognized options of class "critical" that occur in a Non-confirmable message MUST cause the message to be rejected (Section 4.3). '''

Actual Behavior

In this case, we have a Confirmable message containing two occurrences of an unrepeatable option (Uri-Host). While the correct behavior is to reject by sending a 4.02 (Bad Option) , FreeCoAP only complaints against not finding the host.

Steps to reproduce

A Confirmable message with two occurrences of Uri-Host option can be used to reproduce the non-conformance. You can find the Wireshark interaction in the following.

invalid-unrepeatable-options-handling.zip