[rabbitmq-discuss] encoding content body frames

[Ben Hood]

Aman,

On Tue, Jul 15, 2008 at 12:32 AM, Aman Gupta <rabbitmq at tmm1.net> wrote:
> The amqp0-8.pdf spec states:
>
> The content body payload is an opaque binary block followed by a frame end octet:
>
> +-----------------------+ +-----------+
>
> | Opaque binary payload | | frame-end |
>
> +-----------------------+ +-----------+
>
> However, sending the extra frame-end octet with the content causes rabbitmq
> to get "stuck". In fact, this occurs anytime rabbitmq reads more content
> data than it is expecting. Here is a naive patch to ignore extra content in
> the body frame:

Sorry for the delay in responding and thanks for the patch.

Unfortuneately, I would say that the ambiguity of the spec is slightly
to blame here. It does actually say in a footnote that this ending
octet is redundant, hence why it is not used in the frame parser in
Rabbit.

Also, there are a number of clients that currently work well with
Rabbit, so it hasn't been a practical issue thus far either.

This ties in with the weight field in the content header, which was
originally an attempt of allowing a form of MIME-Multipart content
within a body.

As it turned out, this capability became deprecated.

I think that your observations are very valuable because it means that
there are more eyes on the spec, reviewing it and identifying
mistakes.

Ben