<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
After further consideration, I do not agree with this behavior.<br>
<br>
The 1.1 spec specifically shows an example:<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<span class="Apple-style-span" style="color: rgb(102, 102, 102);
font-family: Georgia, Arial, sans-serif; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: 2; text-align: -webkit-auto;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px; -webkit-text-decorations-in-effect:
none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width:
0px; font-size: medium; ">
<pre style="background-color: rgb(248, 248, 255); overflow-x: auto; overflow-y: auto; margin-top: 1em; margin-right: 0px; margin-bottom: 1em; margin-left: 0px; border-top-left-radius: 8px 8px; border-top-right-radius: 8px 8px; border-top-style: solid; border-right-style: solid; border-bottom-style: solid; border-left-style: solid; border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; border-left-width: 1px; border-top-color: rgb(222, 222, 222) !important; border-right-color: rgb(222, 222, 222) !important; border-bottom-color: rgb(222, 222, 222) !important; border-left-color: rgb(222, 222, 222) !important; padding-top: 1em; padding-right: 1em; padding-bottom: 1em; padding-left: 1em; "><code style="font-size: 0.9em; font-family: Monaco, 'Courier New', 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', monospace; font-weight: normal; font-style: normal; ">MESSAGE
foo:World
foo:Hello
^@</code></pre>
</span><br>
The frame above is a MESSAGE frame, and hence must be generated by
the broker.<br>
<br>
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):<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<span class="Apple-style-span" style="color: rgb(102, 102, 102);
font-family: Georgia, Arial, sans-serif; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: 2; text-align: -webkit-auto;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px; -webkit-text-decorations-in-effect:
none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width:
0px; font-size: medium; ">The value of the<span
class="Apple-converted-space"> </span><code style="font-size:
0.9em; font-family: 'Droid Sans Mono', 'Courier New', monospace
!important; ">foo</code><span class="Apple-converted-space"> </span>header
is just<span class="Apple-converted-space"> </span><code
style="font-size: 0.9em; font-family: 'Droid Sans Mono',
'Courier New', monospace !important; ">World</code>.<br>
<br>
</span><br>
<br>
On 11/18/2011 07:10 AM, Guy M. Allard wrote:
<blockquote cite="mid:4EC64B1A.7070400@gmail.com" type="cite">I
agree that is a possible interpretation of the spec.
<br>
<br>
The spec could also be read as: brokers forward as is, clients
deal with the 'SHOULD use only the first' part.
<br>
<br>
I am testing a 1.1 client against Rabbit and Apollo. The behavior
is different.
<br>
<br>
This implementation does seem to imply that a client can not ever
act as a pure server-to-server transfer mechanism.
<br>
<br>
I will deal with either. Thanks for the info that this is
expected.
<br>
<br>
<br>
On 11/18/2011 01:40 AM, Lionel Cons wrote:
<br>
<blockquote type="cite">gmallard<a class="moz-txt-link-rfc2396E" href="mailto:allard.guy.m@gmail.com"><allard.guy.m@gmail.com></a>
writes:
<br>
<blockquote type="cite">I establish a 1.1 level connection, and
send a frame:
<br>
<br>
SEND
<br>
destination:/queue/tq
<br>
dupkey1:latest
<br>
dupkey1:before1
<br>
dupkey1:before2
<br>
<br>
Payload.^@
<br>
<br>
Later I SUBSCRIBE, and receive that message.
<br>
<br>
When the MESSAGE frame comes off the wire, I expect to see all
three
<br>
of those 'dupkey1' headers, in order. I do not. Only the
first of
<br>
the 'dupkey1' headers is present.
<br>
</blockquote>
To my understanding, this is compatible with the STOMP 1.1 spec
that
<br>
says that, in case of repeated header entries, "only the first
header
<br>
entry SHOULD be used as the value". So RabbitMQ just considers
"latest"
<br>
as the value for dupkey1. When it later sends the MESSAGE frame,
only
<br>
this value is sent.
<br>
<br>
Cheers,
<br>
<br>
Lionel
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>