support amqp10 message without body

[thorhalvor]

Proposed Changes

Currently RabbitMQ-server does not support an AMQP 1.0 message with empty/undefined body.
My understanding of the AMQP 1.0 protocol is that this is perfectly valid case.
Many systems sends a message with properties only. They could set an empty array as Body, but that need changes in sometimes hundreds of client-applications.

This change will accept if Body is 'undefined'.

I used AmqpNetLite library and published a message where BodySection is not set

    var message = new Message
    {
        // BodySection = <notset>
        Properties = new Properties()
    };

and the error occured.

Types of Changes

What types of changes does your code introduce to this project?
Put an x in the boxes that apply

• Bug fix (non-breaking change which fixes issue #NNNN)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause an observable behavior change in existing systems)
• Documentation improvements (corrections, new content, etc)
• Cosmetic change (whitespace, formatting, etc)
• Build system and/or CI

Checklist

Put an x in the boxes that apply.
You can also fill these out after creating the PR.
This is simply a reminder of what we are going to look for before merging your code.

• Mandatory: I (or my employer/client) have have signed the CA (see https://github.com/rabbitmq/cla)
• I have read the CONTRIBUTING.md document
• I have added tests that prove my fix is effective or that my feature works
• All tests pass locally with my changes
• If relevant, I have added necessary documentation to https://github.com/rabbitmq/rabbitmq-website
• If relevant, I have added this change to the first version(s) in release-notes that I expect to introduce it

Further Comments

If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution
you did and what alternatives you considered, etc.

[kjnilsson]

@thorhalvor please can you refer to the section of the spec where you got this interpretation? I am not sure it is correct if you look at §3.2 it reads as if only the body is required.

Altogether a message consistsof the following sections:
• Zero or one header.
• Zero or one delivery-annotations.
• Zero or one message-annotations.
• Zero or one properties.
• Zero or one application-properties.
• The body consists of one of the following three choices: one or more data sections, one or more amqp-sequence
sections, or a single amqp-value section.
• Zero or one footer.

[kjnilsson]

I think this PR requires further discussions (with @ansd ) and some research. I read the spec as if the body is required but it isn't completely unambiguous and allowing any non empty bare message sounds like a reasonable request.

[thorhalvor]

When re-reading spec I more or less agree with you @kjnilsson.
However, I still think this is something that should be added into the core

• if not, rabbitmq-server will have a breaking-change from 3.x to 4.x.
• sending a message without body "sounds fair enough". without faking a empty array
• I have tested sending the same message missing BodySection to Azure ServiceBus. it is accepted, no errors
• looks like the empty array is returned from amqp10_framing:decode_bin. if it is decided to be a protocol-error, maybe it should be stopped here? in msg_body_encoded its more a folllow-up error

Awaiting response after you and the team have discussed further.

tnx!

[kjnilsson]

• I have tested sending the same message missing BodySection to Azure ServiceBus. it as accepted, no errors

This is a good data point - thanks for testing this.

[michaelklishin]

The empty body case is valid in both AMQP 1.0 and AMQP 0-9-1. I wouldn't say that it is a common case but if we do not support empty message bodies for AMQP 1.0, then we should at least consider it.

If Azure accepts empty body messages, that's even better. Deviating a bit from the spec is something that protocol implementations almost inevitably have to consider at some point. Open source project maintainers rarely have the time and the patience to try to change the AMQP 1.0 spec over something like this.