[rabbitmq-discuss] temp-queues in STOMP adaptor - missing subscription header

[Toby Corkindale]

On 10/11/11 17:36, Lionel Cons wrote:
> Toby Corkindale writes:
>   >  I've discovered that the /temp-queue/ feature in rabbitmq's stomp
>   >  adaptor causes a problem with at least one STOMP library
>   >  (Net::STOMP::Client).
>   >
>   >  This is because the STOMP specification says that a MESSAGE frame must
>   >  include a "subscription" header.
>   >
>   >  However, messages sent via a temp-queue do not have this header set.
>   >  I can understand why not - it's meaningless - however libraries which
>   >  insist on frames strictly matching the specification will throw an error
>   >  here.
>
> Toby,
>
> Indeed, Net::STOMP::Client checks that the "subscription" header is
> set, as described in the STOMP 1.1 spec.
>
> Since RabbitMQ automatically creates a new subscription (without an
> explicit SUBSCRIBE frame) because of the presence of the
> reply-to:/temp-queue/foo header in a SEND frame, it would make sense
> to use this value (/temp-queue/foo) as the subscription id. After all,
> the purpose of this header is to match a received message with
> something that the client initiated.

I agree, it seems to make sense that RMQ should still set that field. 
Maybe it was just an oversight in the temp-queue code?


> In any case, you can tell Net::STOMP::Client to be less strict about
> protocol validation by tuning $Net::STOMP::Client::Frame::CheckLevel.

Ah, I adjusted it this way:

$Net::STOMP::Client::Protocol::FieldFlags{"1.1"}{MESSAGE}{"subscription"} = 
FLAG_FIELD_OPTIONAL;