Closed hsnaves closed 2 years ago
Hello, and thank you for the issue report and especially the patch!
This is clearly an error in the parser. It certainly shouldn't be taking the next tag=value text as part of the value here. But I am a little uncertain about just applying your patch, because I had a quick look at the FIX standards, and they say
"All tags must have a value specified. Optional fields without values should simply not be specified in the FIX message. A Reject message is the appropriate response to a tag with no value." -- FIX 4.4 with Errata 20030618, page 18.
OTOH, I imagine that you discovered this problem because something is sending you a FIX message with a zero-length value?
I'll think about this over the weekend.
OTOH, I imagine that you discovered this problem because something is sending you a FIX message with a zero-length value?
Yes, I discovered this issue while parsing some malformed FIX messages. I wish all vendors would adhere to the standards, but unfortunately it is not the case.
Do you think a possible compromise/solution could be to parse the message anyway, but issue a warning? Or maybe even better: change the signature of the get_message()
method to something like get_message(self, pedantic=True)
, with an extra parameter that tells the method what to do when it encounters such situations? If the message does not strictly adhere to the standard, and pedantic=True
, the method can then issue an exception.
I've pushed a change that will support this, by configuring the parser.
Instead of eg. p = FixParser()
, you should now do p = FixParser(allow_empty_values=True)
I'll update the doc and push a release to PyPI in a day or so.
Fixed in release v1.0.15 and doc updated.
Thanks again for the report!
Thank you!
Hi,
I noticed one issue with the parser, and would like to submit a patch. I could not attach the patch file to this message (GitHub does not allow the patch extension), so I am sending it below.