Introduction

Oracle Service Bus message context is a set of properties, so called context variables, that hold message content as well as information about messages as they are routed through Oracle Service Bus (OSB). The Message Context Schema specifies the element types for the predefined message context variables.

Such a predefined context variable is the variable attachments.

Fig. 1 shows in an excerpt of the Message Context Schema the definition of the element attachmens.



















     


Fig. 1

Obviously the attachment body can hold either a reference of the content or the content itself!

In this article we analyze what contains exactly the element /mc:attachments/mc:attachment/mc:body and how we can handle its contents.

First of all let us focus on the variables

  • Content-Types
  • Content-Transfer- Encoding

their meanings and their possible values.

Content-Type

According to the W3 specifications (s. [1]) Fig. 2 contains an excerpt of the main characteristics of the variable Content-Type:

An initial set of seven Content-Types is defined by this document. This set of top-level names is intended to be
substantially complete. It is expected that additions to the larger set of supported types can generally be accomplished
by the creation of new subtypes of these initial types. In the future, more top-level types may be defined only by an
extension to this standard. If another primary type is to be used for any reason, it must be given a name starting
with „X-“ to indicate its non-standard status and to avoid a potential conflict with a future official name.
In the Extended BNF notation of RFC 822, a Content-Type header field value is defined as follows:
Content-Type := type „/“ subtype *[„;“ parameter]
type :=  „application“ / „audio“ / „image“ / „message“ / „multipart“ / „text“ / „video“ / x-token
Note also that a subtype specification is MANDATORY. There are no default subtypes.

Fig. 2

Content-Transfer- Encoding

According to the W3 specifications (s. [1]) Fig. 3 contains an excerpt of the main characteristics of the variable Content-Transfer-Encoding:

Unlike Content-Types, a proliferation of Content-Transfer- Encoding values is undesirable and unnecessary.
However, establishing only a single Content-Transfer-Encoding mechanism does not seem possible.
There is a tradeoff between the desire for a compact and efficient encoding of largely-binary data and the desire for
a readable encoding of data that is mostly, but not entirely, 7-bit data. For this reason, at least two encoding
mechanisms are necessary: a „readable“ encoding and a „dense“ encoding.
The Content-Transfer-Encoding field is designed to specify an invertible mapping between the „native“
representation of a type of data and a representation that can be readily exchanged using 7 bit mail transport
protocols, such as those defined by RFC 821 (SMTP). This field has not been defined by any previous standard.
The field’s value is a single token specifying the type of encoding, as enumerated below. Formally:
Content-Transfer-Encoding := „BASE64“ / „QUOTED-PRINTABLE“ / „8BIT“   / „7BIT“ / „BINARY“
/ x-token

Fig. 3

Both variables play a role when a multipart message hits a proxy service that accepts messaging request.

Contents of attachment/body

We can gather the possible combinations of Content-Type and Content-Transfer-encoding in a 2-dimensional Matrix. We ignore the possible values „x-token“ as special cases that are out of scope of this analysis. We will also omit the value „message/*“ as a special case of mail mime attachments, but we will add the possibility of missing one or both of them.

When the content of the attachment body is a reference to a binary content, we need some kind of materialization of the content in order to analyze it, which might be performed through

  • a java callout or
  • a service callout to a simple Proxy-service
 
application/*
audio/*
Image/*
Text/*
Video/*
none
BASE64
By Reference
Content has to be base64 encoded otherwise the attachment is empty.
Reference points to decoded data.
By Reference
Content has to be base64 encoded otherwise the attachment is empty.
Reference points to decoded data.
By Reference
Content has to be base64 encoded otherwise the attachment is empty.
Reference points to decoded data.
By Value
Content has to be base64 encoded otherwise the attachment is empty.
attachment/body contains decoded data.
By Reference
Content has to be base64 encoded otherwise the attachment is empty.
Reference points to decoded data.
By Value
Content has to be base64 encoded otherwise the attachment is empty.
attachment/body contains decoded data.
QUOTED-PRINTABLE
By Reference
Reference points to the original data
By Reference
Reference points to the original data
By Reference
Reference points to the original data
By Value.
attachment/body contains the original data
By Reference
Reference points to the original data
By Value
attachment/body contains the original data
8BIT
By Reference
Reference points to the original data
By Reference
Reference points to the original data
By Reference
Reference points to the original data
By Value.
attachment/body contains the original data
By Reference
Reference points to the original data
By Value
attachment/body contains the original data
7BIT
By Reference
Reference points to the original data
By Reference
Reference points to the original data
By Reference
Reference points to the original data
By Value.
attachment/body contains the original data
By Reference
Reference points to the original data
By Value
attachment/body contains the original data
Binary
By Reference
Reference points to the original data
By Reference
Reference points to the original data
By Reference
Reference contains the original data
By Value.
attachment/body contains the original data
By Reference
Reference points to the original data
By Value
attachment/body contains the original data
none
By Reference
Reference points to the original data
By Reference
Reference points to the original data
By Reference
Reference points to the original data
By Value.
attachment/body contains the original data
By Reference
Reference points to the original data
not valid

Exceptional case

 
application/xml or application/xhtml+xml
BASE64
By Value
if the decoded string is a xml-structure then attachment/body contains this xml-structure rather than a reference to it. If the decoded string is not an xml-structure then the attachment will be rejected.
QUOTED-PRINTABLE
By Value
the data will be passed if contain a valid xml-structure otherwise will be rejected.
8BIT
By Value
the data will be passed if contain a valid xml-structure otherwise will be rejected.
7BIT
By Value
the data will be passed if contain a valid xml-structure otherwise will be rejected.
Binary
By Value
the data will be passed if contain a valid xml-structure otherwise will be rejected.
none
By Value
the data will be passed if contain a valid xml-structure otherwise will be rejected.

Using this matrix one can take the appropriate steps in order to process the contents of the attachments.

Literature

[1] The Content-Type Header Field s. http://www.w3.org/Protocols/rfc1341/4_Content-Type.html

[2] The Content-Transfer-Encoding Header Field s. http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html

[3] MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies

 

Alle Beiträge von Apostolos Varsamis

Schreibe einen Kommentar