Return-Path: Delivered-To: apmail-cxf-issues-archive@www.apache.org Received: (qmail 91395 invoked from network); 12 Feb 2010 15:57:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 12 Feb 2010 15:57:01 -0000 Received: (qmail 78634 invoked by uid 500); 12 Feb 2010 15:57:01 -0000 Delivered-To: apmail-cxf-issues-archive@cxf.apache.org Received: (qmail 78610 invoked by uid 500); 12 Feb 2010 15:57:01 -0000 Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list issues@cxf.apache.org Received: (qmail 78600 invoked by uid 99); 12 Feb 2010 15:57:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Feb 2010 15:57:01 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED,HTTP_ESCAPED_HOST X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Feb 2010 15:56:49 +0000 Received: from brutus.apache.org (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id E7A9B234C1EF for ; Fri, 12 Feb 2010 07:56:27 -0800 (PST) Message-ID: <866119514.234061265990187947.JavaMail.jira@brutus.apache.org> Date: Fri, 12 Feb 2010 15:56:27 +0000 (UTC) From: "Michel Decima (JIRA)" To: issues@cxf.apache.org Subject: [jira] Updated: (CXF-2669) MTOM producer - different content-id in XOP:Include and MIME part for the same attachment In-Reply-To: <389343352.234001265990067921.JavaMail.jira@brutus.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ 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: (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: 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: (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: 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: > 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: > 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.