MTOM producer - different content-id in XOP:Include and MIME part for the same
attachment
-----------------------------------------------------------------------------------------
Key: CXF-2669
URL: https://issues.apache.org/jira/browse/CXF-2669
Project: CXF
Issue Type: Improvement
Components: Core
Affects Versions: 2.2.6
Reporter: Michel Decima
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-3003a2ae8a7...@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%25f...@..." corresponds to
Message-ID: <foo4%f...@...>
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:
63 public static String createContentID(String ns) throws
UnsupportedEncodingException {
64 // tend to change
65 String cid = "http://cxf.apache.org/";;
66
67 String name = ATT_UUID + "-" + String.valueOf(++counter);
68 if (ns != null && (ns.length() > 0)) {
69 try {
70 URI uri = new URI(ns);
71 String host = uri.toURL().getHost();
72 cid = host;
73 } catch (URISyntaxException e) {
74 cid = ns;
75 } catch (MalformedURLException e) {
76 cid = ns;
77 }
78 }
79 return URLEncoder.encode(name, "UTF-8") + "@" + URLEncoder.encode(cid,
"UTF-8");
80 }
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-3003a2ae8a7...@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 :
[email protected]
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
