cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michel Decima (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CXF-2669) MTOM producer - different content-id in XOP:Include and MIME part for the same attachment
Date Fri, 12 Feb 2010 15:56:27 GMT

     [ https://issues.apache.org/jira/browse/CXF-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michel Decima updated CXF-2669:
-------------------------------

    Description: 
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-3003a2ae8a70-4@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%25foo1@..." corresponds to

        Message-ID: <foo4%foo1@...>

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:

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://cxf.apache.org", 
the result will be :

        5726d366-df25-4945-9f3b-3003a2ae8a70-3@cxf.apache.org

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.








  was:
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-3003a2ae8a70-4@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%25foo1@..." corresponds to

        Message-ID: <foo4%foo1@...>

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-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://cxf.apache.org", 
the result will be :

        5726d366-df25-4945-9f3b-3003a2ae8a70-3@cxf.apache.org

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.









> 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-3003a2ae8a70-4@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%25foo1@..." corresponds to
>         Message-ID: <foo4%foo1@...>
> 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:
> 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://cxf.apache.org", 
> the result will be :
>         5726d366-df25-4945-9f3b-3003a2ae8a70-3@cxf.apache.org
> 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.


Mime
View raw message