|
General Q/A
< Previous Next >
Re: Problem while parsing SecureData
John Prewett / Lava Trading
28 May 2009 11:45AM ET > Hi, Can the binary data in the SecureData field contain <SOH> or
> <NULL> within its encrypted data? Has anyone faced a problem while
> parsing such a FIX Logon message that contains a SecureData with <SOH>
> or <NULL>?
>
> Thanks in advance
SecureData can contain absolutely any values including <SOH> and <NULL>. That's the very reason the field is listed as being of type "data". This field must be immediately preceded by SecureDataLen(tag 90) which indicates the actual length of the data. The preceding length field should allow the message parser to skip over embedded <SOH> characters that would otherwise be used to indicate the end of the current tag's value.
If your FIX engine cannot handle a field of type data containing any possible value, it's parsing mechanism is broken.
One other possibility to check is that SecureDataLen immediately precedes SecureData and that its value does indeeed accurately indicate the length of the the SecureData value. If SecureDataLen contains a value that doesn't accurately indicate the length of the SecureData value, the FIX engine parser will have a very, very bad time.
Here is an excerpt from the FIX.5.0SP2 specification volume 1 concerning data field contents:
data: string field containing raw data with no format or content restrictions. Data fields are always immediately preceded by a length field. The length field should specify the number of bytes of the value of the data field (up to but not including the terminating SOH).
Caution: the value of one of these fields may contain the delimiter (SOH) character. Note that the value specified for this field should be followed by the delimiter (SOH) character as all fields are terminated with an "SOH".
JohnP
Re: Problem while parsing SecureData
John Prewett / Lava Trading 28 May 2009 11:45AM ET
|
