So, while this is obviously a bug at some level, I'm not sure at what level we want to say that AMQP intermediaries need to *enforce* compliance with the message format. For one thing there are classes of AMQP intermediary that could totally ignore the message format and simply treat it as opaque data (including message formats other than 0). Also even if the sections match the specification, does a server need to deeply parse the content of the section to ensure that it too is compliant with appropriate definitions (e.g. an amqp-value section that does not contain a single valid amqp value)?
Obviously any intermediary which parses the message sufficiently to discover an error should raise that error (e.g. if the error were between the header and the delivery annotations, then I would expect an intermediary to discover it, and report it (since the intermediary is likely parsing and acting on those sections), however if the error is only after the body then I might not be surprised if the intermediary does not parse the content sufficiently to discover the problem. The ultimate recipient of the message should definitely be parsing it completely and thus should be reporting the error however. As an aside, looking at the code of the Broker-J it looks like that upon meeting a malformed message such as that described, it will throw a ClassCastException and fall over ... I wouldn't say that is optimal behaviour either :-) -- Rob On 23 June 2017 at 19:54, Chuck Rolke <[email protected]> wrote: > AMQP 1.0 spec states a specific order for message format 0 > (MESSAGE-FORMAT). The frames in the jira follow the spec correctly except > they have simple str8-utf8 strings inserted between the major sections. I > just raised issue https://issues.apache.org/jira/browse/PROTON-1509 to > describe the situation in detail. > > * Wireshark correctly calls out the strings as they are encountered in the > message byte stream but it does not throw an expert warning that a string > is not appropriate at that point in the frame. > > * Proton-C ignores the strings and finds later sections. > > * Dispatch ignores the strings and finds later sections. > > * AMQP.Net Lite ignores the strings and finds later sections. AMQP.Net > Lite is a non-qpid implementation. > > I have not tried proton-j. > > Across the board I'd like to see parsers call this some kind of framing > error. Had wireshark done so then Dispatch would not have had the framing > issue for so long. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
