You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@cxf.apache.org by Max Ferrari <ma...@gmail.com> on 2009/12/10 16:39:27 UTC

MTOM producer - different content-id in XOP:Include and MIME part for the same attachment?

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-3003a2ae8a70-4@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

Re: MTOM producer - different content-id in XOP:Include and MIME part for the same attachment?

Posted by Daniel Kulp <dk...@apache.org>.

Can you also check with 2.2.5?   There were some changes around 2.2.2 in the 
xop CID handling.     I'm curious if that may "help" or not.

Dan

On Fri December 11 2009 5:03:36 am 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 <ma...@gmail.com>:
> > 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@bar.net" corresponds to
> >
> >        Message-ID: <fo...@bar.net>
> >
> > 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-3003a2ae8a70-4@http://cxf.apache.org/>
> >
> > whereas as per the RFC example one would expect
> >
> > Content-ID:
> > <5726d366-df25-4945-9f3b-3003a2ae8a70-4@http%3A%2F%2Fcxf.apache.org%2F>
> >
> > This breaks interoperability with other consumers (servers) at the
> > moment.
> >
> > 2009/12/11 Max Ferrari <ma...@gmail.com>:
> >> I've just found this:
> >> https://issues.apache.org/jira/browse/CXF-596?page=com.atlassian.jira.pl
> >>ugin.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 <ma...@gmail.com>:
> >>> 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.apach
> >>>e.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/>
> >>>
> >>> 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
> 

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

Re: MTOM producer - different content-id in XOP:Include and MIME part for the same attachment?

Posted by Daniel Kulp <dk...@apache.org>.

Patch applied.    Tomorrows snapshots should have it.

Dan


On Fri February 12 2010 11:05:25 am Michel Decima wrote:
> Hi Dan,
> 
> dkulp wrote:
> > I'd be ok changing the default if it would be more interopable.
> > 
> > Please file a JIRA with a patch.  :-)
> 
> Here it is:
> 
> JIRA CXF-2669 - MTOM producer - different content-id in XOP:Include and
> MIME part for the same attachment
> https://issues.apache.org/jira/browse/CXF-2669?page=com.atlassian.jira.plug
> in.system.issuetabpanels:all-tabpanel
> 
> Thank you for support.

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

Re: MTOM producer - different content-id in XOP:Include and MIME part for the same attachment?

Posted by Michel Decima <mi...@orange-ftgroup.com>.

Hi Dan,


dkulp wrote:
> 
> I'd be ok changing the default if it would be more interopable.
> 
> Please file a JIRA with a patch.  :-)
> 

Here it is:

JIRA CXF-2669 - MTOM producer - different content-id in XOP:Include and MIME
part for the same attachment
https://issues.apache.org/jira/browse/CXF-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Thank you for support.


-- 
View this message in context: http://old.nabble.com/MTOM-producer---different-content-id-in-XOP%3AInclude-and-MIME-part-for--the-same-attachment--tp26729418p27565715.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: MTOM producer - different content-id in XOP:Include and MIME part for the same attachment?

Posted by Daniel Kulp <dk...@apache.org>.

I'd be ok changing the default if it would be more interopable.

Please file a JIRA with a patch.  :-)

Dan


On Wed February 10 2010 11:15:46 am Michel Decima wrote:
> Hello,
> 
> We are facing exactly the same issue here : third-party server unable to
> handle
> attachment sent by MTOM producer because of escaped cid:
> 
> Max Ferrari wrote:
> >> 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)
> 
> Thanks to Max, I understand that the behaviour of CXF according to RFC2111,
> and the third-party server should handle hex-escaped cid values. However,
> the server vendor can't provide a solution, because the external library
> they use to process attachments does not handle hex-escaped values, and
> they can't upgrade easily to another library.
> 
> So I browsed the CXF source tree to see how the cid and Contend-ID are
> generated. In class org.apache.cxf.attachment.AttachmentUtil, we have:
> 
> 
> 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-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://foo.bar.com", the
> result
> will be :
> 
>         5726d366-df25-4945-9f3b-3003a2ae8a70-3@foo.bar.com
> 
> and this string value does not contains hex-escaped characters.
> 
> 
> So I searched a way to specify a custom namespace to createContentID from
> my client code generated from WSDL by $CXF_HOME/bin/wsld2java, but I did
> not found how to do it. Is it possible ? (if yes, problem solved).
> 
> Then, I took a closer look to the createContentId() function, and I think
> that its behaviour is not very coherent : if the namespace (ns) is not
> null, only the host part is used, but if it is null, the full URL
> "http://cxf.apache.org/"
> with "http://" prefix is used. 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 :
> 
>     String s1 = AttachmentUtil.createContentID( "" ) ;
>     String s2 = AttachmentUtil.createContentID( "http://cxf.apache.org/" )
> ; assert s1.substring( s1.indexOf('@')).equals( s2.substring(
> s2.indexOf('@')) );
> 
> Currently, the assertion above fails, and obviously we just have to change
> the default cid value line 65 :
> 
> 65  String cid = "cxf.apache.org" ;  // was "http://cxf.apache.org/"
> 
> 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 our current
> server.
> 
> What do you think ?
> 
> Best Regards,
> 
> --
> Michel Decima.

-- 
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog

Re: MTOM producer - different content-id in XOP:Include and MIME part for the same attachment?

Posted by William Tam <em...@gmail.com>.

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 <ma...@gmail.com>:
>   
>> 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@bar.net" corresponds to
>>
>>        Message-ID: <fo...@bar.net>
>>
>> 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-3003a2ae8a70-4@http://cxf.apache.org/>
>>
>> whereas as per the RFC example one would expect
>>
>> Content-ID: <5726d366-df25-4945-9f3b-3003a2ae8a70-4@http%3A%2F%2Fcxf.apache.org%2F>
>>
>> This breaks interoperability with other consumers (servers) at the moment.
>>
>>
>> 2009/12/11 Max Ferrari <ma...@gmail.com>:
>>     
>>> 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 <ma...@gmail.com>:
>>>       
>>>> 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-3003a2ae8a70-4@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
>>
>>     
>
>
>
>

Re: MTOM producer - different content-id in XOP:Include and MIME part for the same attachment?

Posted by Michel Decima <mi...@orange-ftgroup.com>.

Hello,

We are facing exactly the same issue here : third-party server unable to
handle
attachment sent by MTOM producer because of escaped cid:

Max Ferrari wrote:
> 
>> 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) 
> 

Thanks to Max, I understand that the behaviour of CXF according to RFC2111,
and the third-party server should handle hex-escaped cid values. However,
the server vendor can't provide a solution, because the external library
they use to process attachments does not handle hex-escaped values, and 
they can't upgrade easily to another library.

So I browsed the CXF source tree to see how the cid and Contend-ID are
generated. In class org.apache.cxf.attachment.AttachmentUtil, we have:

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-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://foo.bar.com", the
result
will be :

        5726d366-df25-4945-9f3b-3003a2ae8a70-3@foo.bar.com

and this string value does not contains hex-escaped characters.

So I searched a way to specify a custom namespace to createContentID from
my client code generated from WSDL by $CXF_HOME/bin/wsld2java, but I did not
found how to do it. Is it possible ? (if yes, problem solved).

Then, I took a closer look to the createContentId() function, and I think
that its behaviour is not very coherent : if the namespace (ns) is not null,
only the host part is used, but if it is null, the full URL
"http://cxf.apache.org/"
with "http://" prefix is used. 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 :

    String s1 = AttachmentUtil.createContentID( "" ) ;
    String s2 = AttachmentUtil.createContentID( "http://cxf.apache.org/" ) ;
    assert s1.substring( s1.indexOf('@')).equals( s2.substring(
s2.indexOf('@')) );

Currently, the assertion above fails, and obviously we just have to change
the default cid value line 65 :

65  String cid = "cxf.apache.org" ;  // was "http://cxf.apache.org/"

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 our current
server.

What do you think ?

Best Regards,

--
Michel Decima.

-- 
View this message in context: http://old.nabble.com/MTOM-producer---different-content-id-in-XOP%3AInclude-and-MIME-part-for--the-same-attachment--tp26729418p27533761.html
Sent from the cxf-user mailing list archive at Nabble.com.