camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Ferrari <>
Subject Re: MTOM producer - different content-id in XOP:Include and MIME part for the same attachment?
Date Fri, 11 Dec 2009 10:01:39 GMT
>From RFC2111 (

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, "" corresponds to

        Message-ID: <>

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:


Content-ID: <5726d366-df25-4945-9f3b-3003a2ae8a70-4@>

whereas as per the RFC example one would expect

Content-ID: <>

This breaks interoperability with other consumers (servers) at the moment.

2009/12/11 Max Ferrari <>:
> I've just found this:
> 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 <>:
>> 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
>> 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=""
>> href=""/>
>> (please notice escaped URI in the cid)
>> - instead, the actual Content-Id in the multipart POST part is unescaped:
>> Content-ID: <5726d366-df25-4945-9f3b-3003a2ae8a70-4@>
>> 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=""
>> href="cid:5726d366-df25-4945-9f3b-3003a2ae8a70-3@"/>
>> 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
>> 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


View raw message