qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Godfrey <rob.j.godf...@gmail.com>
Subject Re: Use of content-type in AMQP 1.0
Date Tue, 09 Sep 2014 10:31:17 GMT
Hi Frase,

ignoring any transformations that may take place in a client library
between setting the content type in the API and what actually goes out on
the wire... the AMQP 1.0 specification defines content-type as follows
(see:
http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-properties
):

The RFC-2046 [RFC2046
> <http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-overview-v1.0-os.html#anchor-RFC2046>]
> MIME type for the message's application-data section (body). As per
> RFC-2046 [RFC2046
> <http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-overview-v1.0-os.html#anchor-RFC2046>]
> this can contain a charset parameter defining the character encoding used:
> e.g., 'text/plain; charset="utf-8"'.
> For clarity, as per section 7.2.1 of RFC-2616 [RFC2616
> <http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-overview-v1.0-os.html#anchor-RFC2616>],
> where the content type is unknown the content-type SHOULD NOT be set. This
> allows the recipient the opportunity to determine the actual type. Where
> the section is known to be truly opaque binary data, the content-type
> SHOULD be set to application/octet-stream.
> When using an application-data section with a section code other than
> *data*, content-type SHOULD NOT be set.


So, in essence the content type is (only) to be used when the data is being
sent as an opaque "data" section and in that case it enables the recipient
to interpret the opaque data cofrrectly

Hope this helps,
Rob



On 8 September 2014 20:01, Fraser Adams <fraser.adams@blueyonder.co.uk>
wrote:

> Gordon's recent post
>
> When the message is created it looks like this:
>
>      std::string messageContent("example text");
>      qpidMessage.setContentType("text/plain");
>      qpidMessage.setContent(qpid::types::Variant(messageContent));
>
> Use Message::setContentObject() instead and set the encoding, e.g. change
> the last line to:
>
>       qpidMessage.setContentObject(messageContent);
>       qpidMessage.getContentObject().setEncoding("utf8");
>
>
>
> prompted me to ponder about what and what is not the correct use of
> content-type in AMQP 1.0.
>
> So for AMQP 0.10 IIRC in qpid::messaging the content type was used to
> indicate certain AMQP types, for example in particular amqp/list and
> amqp/map now as I understand it for AMQP 1.0 the AMQP type system is
> sufficiently self-describing such that maps/lists/whatever don't need such
> things as content-type, however the various APIs do need some mechanism to
> specify the relevant type hence (I think) the setContentObject() mechanism
> in qpid::messaging
>
> is that correct?
>
>
> Why I ask is that for my JavaScript stuff although I've incorporated a
> mechanism to automagically serialise and deserialise JavaScript Objects to
> the AMQP type system I also quite fancy including a mechanism that takes a
> JavaScript Object and serialises it as JSON in an AMQP String (obviously
> assuming that it is a data object that is actually convertable to JSON)
> similarly I'd like to be able to receive a JSON object and deserialise it
> into a JavaScript object.
>
> My thinking is that this is actually a good use of the AMQP content-type
> and in this case setting content-type to "application/json" is the right
> thing to do to give the API the right hints to treat Strings as JSON.
>
> Is my logic and understanding of the use of content-type in the AMQP 1.0
> spec. reasonable?
>
> Frase
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message