[rabbitmq-discuss] Bug/Behavior Change in binds to header exchanges in rabbitmq 3.1.0

[Matthias Radestock]

Matt,

On 03/05/13 16:19, Matt Campbell wrote:
> In rabbit 3.0.4 and 2.8.7, I was able to bind a queue to a headers
> exchange without specifying any bind arguments, which resulted in that
> queue receiving all the messages. In rabbit 3.1.0, when I make that same
> bind I get an error message telling me I must include the "x-match"
> header. While this is an irritation for clients that use AMQP or the
> HTTP API to create the binds (because they require a code change), I
> have some clients that bind queues to this exchange via STOMP and I am
> unaware of how to get that header set through a STOMP subscribe to that
> exchange.
>
> Is this an intended behavior change going forward, or is this a bug in
> rabbitmq 3.1.0?

We introduced validation of the x-match header in 3.1 - a change that 
unfortunately didn't get mentioned in the release notes.

As part of that, bindings with no x-match header are now rejected 
whereas previously they would be treated as 'all' matches.

The spec is vague in this regard; it neither says that x-match must be 
present nor what should happen when it isn't.

I have filed a bug to explore whether we should revert to the original 
behaviour, though given the spec vagueness it is probably best not to 
depend on that in applications.

As an alternative to changing the bindings in your code, you could 
introduce an intermediate fanout exchange, either

a) in front of the headers exchange, with publishers publishing to that 
instead of the headers exchange, or

b) behind the headers exchange, bound to it with x-match=all, so that 
selected queues can bind to that w/o having to set a header

Regards,

Matthias.