Details
Description
I have encountered a counterparty whose FIX 4.2 Logon message has "98=0" appearing twice. It's clearly wrong, but I couldn't find anywhere in the spec that prohibits it.
We choke on these messages pretty early with the not-too-helpful (see QFJ-65) message "Invalid message: Actual body length=x, Expected body length=x".
The Message.bodyLength() method adds up the lengths of the fields after they've been parsed and grouped as per the DataDictionary, thus the duplicated "98=0" field only gets counted once.
I have added a crude "ValidateMessageStructure=N" work-around for myself which disables the whole bodyLength() validation step (as well as the innocent checkSum and header field order checks). I will attach this hack as a patch against SVN revision 571.
A better solution would be to re-think the bodyLength() validation, could it not just examine the raw (unparsed, ungrouped) message at this point, like checkSum() does?