[rabbitmq-discuss] STOMP 1.1 Repeated Headers

[Guy M. Allard]

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

The 1.1 spec specifically shows an example:

|MESSAGE
foo:World
foo:Hello

^@|


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

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>