[rabbitmq-discuss] STOMP 1.1 Repeated Headers

Guy M. Allard allard.guy.m at gmail.com
Tue Nov 29 02:54:19 GMT 2011

After further consideration, I do not agree with this behavior.

The 1.1 spec specifically shows an example:



The frame above is a MESSAGE frame, and hence must be generated by the 

The implication is that this frame is presented to the client as-is, and 
the client is left to deal with (quote from the spec):

The value of the|foo|header is just|World|.

On 11/18/2011 07:10 AM, Guy M. Allard wrote:
> I agree that is a possible interpretation of the spec.
> The spec could also be read as:  brokers forward as is,  clients deal 
> with the 'SHOULD use only the first' part.
> I am testing a 1.1 client against Rabbit and Apollo.  The behavior is 
> different.
> This implementation does seem to imply that a client can not ever act 
> as a pure server-to-server transfer mechanism.
> I will deal with either.  Thanks for the info that this is expected.
> On 11/18/2011 01:40 AM, Lionel Cons wrote:
>> gmallard<allard.guy.m at gmail.com>  writes:
>>> I establish a 1.1 level connection, and send a frame:
>>> SEND
>>> destination:/queue/tq
>>> dupkey1:latest
>>> dupkey1:before1
>>> dupkey1:before2
>>> Payload.^@
>>> Later I SUBSCRIBE, and receive that message.
>>> When the MESSAGE frame comes off the wire, I expect to see all three
>>> of those 'dupkey1' headers, in order.  I do not.  Only the first of
>>> the 'dupkey1' headers is present.
>> To my understanding, this is compatible with the STOMP 1.1 spec that
>> says that, in case of repeated header entries, "only the first header
>> entry SHOULD be used as the value". So RabbitMQ just considers "latest"
>> as the value for dupkey1. When it later sends the MESSAGE frame, only
>> this value is sent.
>> Cheers,
>> Lionel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111128/73c3b0bd/attachment.htm>

More information about the rabbitmq-discuss mailing list