Repeated Headers and Specification Requirements

[gmallard]

I would like to suggest additional clarification(s) in the
specification section: http://stomp.github.com/stomp-specification-1.1.html#Repeated_Header_Entries

That section is quoted here:

<q>
Since messaging systems can be organized in store and forward
topologies, similar to SMTP, a message may traverse several messaging
servers before reaching a consumer. The intermediate server MAY
'update' header values by either prepending headers to the message or
modifying a header in-place in the message.
If the client receives repeated frame header entries, only the first
header entry SHOULD be used as the value of header entry. Subsequent
values are only used to maintain a history of state changes of the
header. For example, if the client receives:

MESSAGE
foo:World
foo:Hello

^@

The value of the foo header is just World.
</q>

My motivation: I am testing several new client libraries against
different brokers, and I observe different broker behavior.

Behaviors Observed:

1) The 'foo:Hello' header is presented by broker1
2) The 'foo:Hello' header is *not* presented by broker2

I suggest that the specification language be changed to include
(roughly) one of the following:

a) brokers MUST/MUST NOT emit duplicate headers
b) brokers SHOULD/SHOULD NOT emit duplicate headers
c) brokers MAY emit duplicate headers with documentation of conditions
d) a better suggestion from some one else?

In short: I would very much like to avoid a client library that must
guess at what a particular broker will do.

Thanks for your consideration of this.

Regards, Guy

[Hiram Chirino]

Hi Guy,

As it's documented now, the spec is in condition c.
The simplest road to take is that a client library should only return
the value of the first duplicate header when a header value is looked
up.

Regards,
Hiram

FuseSource
Web: http://fusesource.com/

[gmallard]

Hi Hiram - I have no problem with any of the conditions mentioned. I
can deal with any of them in client library code.

But can we please explicitly say: ".... the broker MAY ........" with
appropriate other verbiage? And perhaps an expanded example?

I find the current specification wording and example not clear/
precise.

The current specification example shows a frame from the broker only,
not an example of what a client can send with what may be returned.

I believe that clients reading the spec need to clearly understand
that behavior will depend on the broker implementation.

Regards, Guy

On Nov 29, 8:24 pm, Hiram Chirino <hi...@hiramchirino.com> wrote:
> Hi Guy,
>
> As it's documented now, the spec is in condition c.
> The simplest road to take is that a client library should only return
> the value of the first duplicate header when a header value is looked
> up.
>
> Regards,
> Hiram
>
> FuseSource
> Web:http://fusesource.com/
>
>
>
>
>
>
>
> On Tue, Nov 29, 2011 at 7:59 PM, gmallard <allard.gu...@gmail.com> wrote:
> > I would like to suggest additional clarification(s) in the

> > specification section:http://stomp.github.com/stomp-specification-1.1.html#Repeated_Header_...

[Hiram Chirino]

Sure. Feel free to send us a patch with the verbiage you think clarifies it.

Regards,
Hiram

FuseSource
Web: http://fusesource.com/

[gmallard]

I am going to resurrect this horse so I can beat it some more.

The spec verbiage leads to this current state of affairs:

<stdout>

Broker: apache-apollo/99-trunk-SNAPSHOT

Headers Sent:

keya:value3

keya:value2

keya:value1

Headers Received:

keya:value3

keya:value2

keya:value1

Broker: RabbitMQ 2.6.1

Headers Sent:

keya:value3

keya:value2

keya:value1

Headers Received:

keya:value3

Broker: ActiveMQ/5.6.0

Headers Sent:

keya:value3

keya:value2

keya:value1

Headers Received:

keya:value1

</stdout>

Imagine that a chain of client relays is being designed, using logic based on repeated headers.  Given the above broker behaviors, it seems impossible to implement such a chain in a broker-agnostic way, or to construct a chain that operates with heterogeneous brokers.

For now I will merely repeat that I believe this is a case where some restrictions on broker behavior need to be documented in the spec.

Guy

[Hiram Chirino]

Yeah, looks like ActiveMQ/5.6.0 is broken in regards to the 1.1 spec.  I've opened issue:

https://issues.apache.org/jira/browse/AMQ-3929

So that it can be fixed for the next release.

--

Hiram Chirino

Software Fellow | FuseSource Corp.

chi...@fusesource.com | fusesource.com

skype: hiramchirino | twitter: @hiramchirino

blog: Hiram Chirino's Bit Mojo