[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
> 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:
>>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss