How we should behave with uncompliant / bad header

[sbernard31]

I think we should decide what we should do with uncompliant / bad header.

I know by the past "robustness principle" was preferred but I don't like to much the idea at least as default behavior.
I write my opinion about it in Leshan wiki : https://github.com/eclipse-leshan/leshan/wiki/How-Leshan-should-behave-with-Non-Compliant-Implementations-%3F

So I prefer a strict Compliance by default meaning that each unexpected format of data will raise an exception.
Or at very least will raise a log.
My preferred way would be raise an exception by default and eventually be able to configure (or override code) to let user log instead.

Here is some part of the code which lead to that kind of questions :

• RAV-2958 - Initial Proxy Protocol processing #1 (comment)
• RAV-2958 - Initial Proxy Protocol processing #1 (comment)
• And also check expected value for local command :

  proxy-socket-java/proxy-socket-core/src/main/java/net/airvantage/proxysocket/core/v2/ProxyProtocolV2Decoder.java

  Lines 64 to 66 in 175c850

  	case 0x00:
  	// Early return for LOCAL command
  	return new ProxyHeader(ProxyHeader.Command.LOCAL, ProxyHeader.AddressFamily.AF_UNSPEC, ProxyHeader.TransportProtocol.UNSPEC, null, null, null, PROTOCOL_SIGNATURE_FIXED_LENGTH);

[bplessis-swi]

You and @cthirouin-swi were in agreement on this so the exception road was taken for tlv parsing.

[sbernard31]

I think this also make sense to check the value of LOCAL command.

[sbernard31]

(Not directly linked so let me know if you prefer a dedicated issue)
But We could also discuss what should be the behavior if we receive a not supported format :
See : #1 (comment)