[rabbitmq-discuss] rabbitmq-stomp 2.5.1 does not respect the spec wrt content-type

[Tony Garnock-Jones]

[resending because numpty here forgot to reply-to-all. Sorry!]

On 9 August 2011 11:24, Steve Powell <steve at rabbitmq.com> wrote:

> Thanks for the confirmation that you included a content-length.  Any ideas
> on the proper behaviour when it is omitted?
>

Content-length should only control the frame delimiting process, and
shouldn't make any difference to the interpretation of the content of a
message.

Indeed, we would never want to add incorrect information to a message.  In
> this case, we clearly make the wrong default assumption.
>

If the content-type is absent when the broker receives a message, it should
remain absent when the broker processes and relays on that message. The
broker should *never* synthesize a content-type header.

Of course, knowing what the defaults MUST be is surely better than only
> knowing what they SHOULD be.  Perhaps you can help to improve the
> specification for us here.
>

Perhaps in section "Header content-type" the first paragraph could be
augmented with the sentence "A message broker or other relay MUST NOT
attempt to guess a content-type if one is not specified by the original
sender of a message."

I can see where the confusion arose: there's a sentence in that section, "It
SHOULD be set to a mime type which describes the format of the body to help
the receiver of the frame interpret it's contents", which chooses the word
"set" poorly. That sentence should probably be changed to read "When
present, the content-type header SHOULD be interpreted as being a mime type
which describes the format of the body to help the receiver of the frame
interpret its contents", as well, thus avoiding the suggestion that a relay
should "set" the header on the SENDer's behalf.

Cheers,
  Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110809/31c14529/attachment.htm>