Major Description
Some third-party server can't receive MTOM attachment sent by CXF clients
because "cid" URL and Content-ID are different.
- In the SOAP part of the request the attachments are included as:
<xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include"
href="cid:5726d366-df25-4945-9f3b-3003a2ae8a70-3@http%3A%2F%2Fcxf.apache.org%2F"/>
(please notice escaped cxf.apache.org URI in the cid)
- instead, the actual Content-Id in the multipart POST part is unescaped:
Content-ID: <5726d366-df25-4945-9f3b-3003a2ae8a70-4@http://cxf.apache.org/>
From RFC2111 (http://www.ietf.org/rfc/rfc2111.txt) :
A "cid" URL is converted to the corresponding Content-ID message
header [MIME] by removing the "cid:" prefix, converting %hh hex-
escaped characters to their ASCII equivalents and enclosing the
remaining parts with an angle bracket pair, "<" and ">". For
example, "mid:foo4%25foo1@..." corresponds to
Message-ID: <foo4%foo1@...>
According to this RFC, the "cid" URL and Content-ID are perfectly legal.
However, the behaviour of the function createContentID() from class
org.apache.cxf.attachment.AttachmentUtil is not very consistent:
The full content-id is the result of concatenation of a random part (name) and a
suffix part (cid) after encoding with URLencoder.
If the argument ns is null or empty, the suffix defaults to
"http://cxf.apache.org" (full absolute URL, not the host part of it), and
then the result of the function will contain hex-escaped characters, like
this:
5726d366-df25-4945-9f3b-3003a2ae8a70-3@http%3A%2F%2Fcxf.apache.org%2F
If the argument ns is not null and not empty, then ns is used to build an
URL, and the host part of this URL will be used as suffix value. Thus, if we
call this function with a specific namespace, for example "http://cxf.apache.org",
the result will be :
5726d366-df25-4945-9f3b-3003a2ae8a70-3@cxf.apache.org
and this string value does not contains hex-escaped characters.
To be more consistent, the function should use only the host part "cxf.apache.org"
if namespace is null/empty. In other words, calling createContentId() explicitely
with empty namespace and "http://cxf.apache.org/" should give the same value for
the suffix part (after character @).
Since this modification affects only the default suffix value, the algorithm
stays the same, and hex-escaped characters are processed as expected. But, as
a side effect, the generated contentID will be compatible with current third-party
server.