You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Michel Decima <mi...@orange-ftgroup.com> on 2010/02/10 17:15:46 UTC
Re: MTOM producer - different content-id in XOP:Include and MIME
part for the same attachment?
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.
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