error handling for malformed messages

[Ilmarinen100]

VISSv2 core&transport leave the exact error reply in following cases unclear:

• JSON from WebSocket-client cannot be parsed (e.g. missing curly brace)
• JSON from WebSocket-client does not contain an action (or a non-existing action)
• JSON from WebSocket-client lacks a requestID (or has one with a wrong type, e.g. an array [] )

[tguild]

@Ilmarinen100 can you elaborate, how did you get this error message? was this from the reference implementation

[Ilmarinen100]

@tguild we are working on an implementation of a VISSv2 server and we are wondering how the server should react to clients sending malformed requests as listed above. Reading core&transport standard, we did not find a clear answer for the listed cases.

Does the absence of clear spec mean it is ok if the server simply ignore incoming websocket messages that do not satisfy such basic protocol properties? (or should it answer with error messages that do not contain a requestID/action because none could be parsed from the incoming message)

[tguild]

@Ilmarinen100 interesting, can you share who "we" are. we're naturally curious who is implementing, how (use cases) and happy to give feedback and want to learn about problems you're encountering. I appreciate that you might not be able to divulge much, whatever you're comfortable with and can discuss somewhere other than in a public github issue.

[Ilmarinen100]

@tguild "we" is a consulting company working in the automotive sector. (I can't divulge more)

For the scope of our work the above question is not a blocker but we think the standard should be clearer with regards to corner cases in error handling. (or alternatively simply define that messages that do not satisfy basic requirements may be ignored completely by a VISSv2 server)

[UlfBj]

In he Transport spec, chapter 4.1 Status codes there is 400 (Bad Request) | bad_request | The server is unable to fulfil the client request because the request is malformed.

So at least there is an error code assigned to it. But I agree that it should be explicitly stated somewhere in the spec that this error code should be used for those cases.

[Ilmarinen100]

@UlfBj : but should the bad_request be sent out in a message that only has "action" and "requestId" fields if parsing of a string value was possible from the request (and not contain those fields otherwise)

[UlfBj]

Your questions have made it clear to me that the specs are not sufficiently clear, or even correct, when it comes to describing the error handling/message. It will for one be different or HTTP than for the other protocols. Current description in Core seems to describe the HTTP case, and not the others. Generally, I think that an error message shall be returned, if at all possible. For HTTP I believe it is basically always possible. For the others it seems to require that the requestId can be recovered, else it is not possible to route it back to the correct request sender. The spec needs to be updated to describe this as I see it.

[UlfBj]

Fixed in PR476