Thanks Max, for the investigating the issue and posting back the outcome.
Max Ferrari wrote:
Apologies,
I skipped the part where it says
"converting %hh hex-escaped characters to their ASCII equivalents".
Indeed this is a client issue (third party).
2009/12/11 Max Ferrari <[email protected]>:
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%[email protected]" corresponds to
Message-ID: <foo4%[email protected]>
What happens in CXF 2.2 also after the fix to issue CXF-596 is that
the "cid" URL is converted to a completely unescaped Content-ID in the
MIME header, so we have for example:
cid:5726d366-df25-4945-9f3b-3003a2ae8a70-3@http%3A%2F%2Fcxf.apache.org%2F
becomes
Content-ID: <5726d366-df25-4945-9f3b-3003a2ae8a7...@http://cxf.apache.org/>
whereas as per the RFC example one would expect
Content-ID:
<5726d366-df25-4945-9f3b-3003a2ae8a7...@http%3a%2f%2fcxf.apache.org%2f>
This breaks interoperability with other consumers (servers) at the moment.
2009/12/11 Max Ferrari <[email protected]>:
I've just found this:
https://issues.apache.org/jira/browse/CXF-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
The fix applies to CXF 2.0, we're using CXF 2.2 and still experience
something very similar; possibly a Camel issue? We're using camel-cxf
1.6.2.
Can't find anything on Camel's Jira, crossposting to camel-users.
2009/12/10 Max Ferrari <[email protected]>:
Hi List,
we are using in a camel route a cxf producer (client) enpoint with
MTOM enabled.
The consumer (server) at the moment is a 'black box' sitting in our
customer's environment.
The issue:
following to an (apparently) valid request from our CXF client, the
server replies with a SOAP fault:
<SOAP-ENV:Fault><faultcode>Sender</faultcode><faultstring>cannot get
mime part</faultstring></SOAP-ENV:Fault>
I've analyzed the http conversation and I observe that:
- 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/>
The point is that, if I replay using Fiddler the same request, by
replacing the escaped part of the cid with an unescaped one, so that
XOP and MIME content IDs are exactly the same:
<xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include";
href="cid:5726d366-df25-4945-9f3b-3003a2ae8a70-3@http://cxf.apache.org/"/>
then the server replies with a 200 OK.
Now, I suspect that the escaped cid in the SOAP part is perfectly
legal and that it's the consumer implementation's fault not matching
it correctly to the MIME part.
However I'd need some clear normative references to discuss this to
the customer.
Actually at http://www.w3.org/TR/2004/CR-xop10-20040826/#mime_xop_packages
I read:
Part metadata is reflected in MIME header fields. Specifically, the
URI used in the value of an href attribute information item on a
xop:Include element information item contains a URI that uses the
'cid:' scheme (see [RFC 2392]), so the corresponding MIME part MUST
have a Content-ID header field (see [RFC 2387] with a corresponding
field-value.
Some comments from CXF developers would be greatly appreciated.
Thanks
Max
--
Max
