Imported from previous forum
Are all header fields required to appear before any body field? I am testing with version 4.0.
According to the spec:
"The general format of a FIX message is a standard header followed by the message body fields and terminated with a standard trailer"
but it also states:
"Except where noted, fields within a message can be defined in any sequence (i.e. relative position of a field within a record is inconsequential); exceptions are explicitly defined otherwise (certain header fields and fields within repeating data groups). ".
[ original email was from John Prewett - jprewett@lavatrading.com ]
It most certainly was the intention that the field order should be:
All header fields followed by
All body fields followed by
All trailer fields
Unfortunately not everyone seemed to correctly interpret this rule, including (but not limited to) one very mainstream FIX engine 
So common sense must be used:
- Obey the protocol rules to the strictest degree when sending messages.
- Be as lenient as possible over protocol rules when receiving messages.
In this case, it means you must be prepared to receive some header fields after some body fields or you may not be able to communicate.
Ed,
In my experience with 4.0 implementions in the past, there was a tendancy on the implementors’ part to not follow the “header-body-trailer” format as closely as when later versions are implemented. This was partly because of the ambiguity of the second statement you pointed out. 4.2 tighted down the bolt on this requirement that header fields must come before mesg body fields, but the order within each segment is inconsequential, with exception that the first 3 fields of the header (tags 8, 9 and 35), the checksum field must be last, and fields in repeating groups must be in order specified. Many implementors later point to 4.2 as the guideline to follow even for a 4.0 implementation.
> Are all header fields required to appear before any body field? I am testing with version 4.0.
>
> According to the spec:
> "The general format of a FIX message is a standard header followed by the message body fields and terminated with a standard trailer"
>
> but it also states:
> "Except where noted, fields within a message can be defined in any sequence (i.e. relative position of a field within a record is inconsequential); exceptions are explicitly defined otherwise (certain header fields and fields within repeating data groups). ".
>
>
>
Thanks for the replies.
Just a thought about why I thought the hdr followed by body statement wasn’t meant to be strictly interpretted. It cannot hold up in the presence of secure data.
I’m not sure why header before body before trailer “cannot hold up in the presence of secure data”. The SecureData field (tag 91) is part of the Standard Header. Assuming you populate/place the SecureData at the end of your non-encrypted set of header fields, then you should have header-body-trailer.
> Thanks for the replies.
>
> Just a thought about why I thought the hdr followed by body statement wasn’t meant to be strictly interpretted. It cannot hold up in the presence of secure data.
>
I should have been more specific. It cannot hold up as a necessary condition for correctness. The spec does not require that tag 91 is the last non-encrypted header field. So I don’t think the spec as written can be used to enforce header-body-trailer field ordering as a necessary condition for correctness.
> I’m not sure why header before body before trailer “cannot hold up in the presence of secure data”. The SecureData field (tag 91) is part of the Standard Header. Assuming you populate/place the SecureData at the end of your non-encrypted set of header fields, then you should have header-body-trailer.
>
> > Thanks for the replies.
> >
> > Just a thought about why I thought the hdr followed by body statement wasn’t meant to be strictly interpretted. It cannot hold up in the presence of secure data.
> >
>
[ original email was from Atul Pandya - atul.pandya@fmr.com ]
In my experience, the FIX engines also impose the strictness of this rule and reject messages that intermix header and body fields.
This is good and bad both. Bad since it is difficult to figure out why a message was rejected and requires manual scanning.
Atul
> I should have been more specific. It cannot hold up as a necessary condition for correctness. The spec does not require that tag 91 is the last non-encrypted header field. So I don’t think the spec as written can be used to enforce header-body-trailer field ordering as a necessary condition for correctness.
>
> > I’m not sure why header before body before trailer “cannot hold up in the presence of secure data”. The SecureData field (tag 91) is part of the Standard Header. Assuming you populate/place the SecureData at the end of your non-encrypted set of header fields, then you should have header-body-trailer.
> >
> > > Thanks for the replies.
> > >
> > > Just a thought about why I thought the hdr followed by body statement wasn’t meant to be strictly interpretted. It cannot hold up in the presence of secure data.
> > >
> >
>