Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of email.wtam@gmail.com designates
 209.85.211.182 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=J651+UAx02tvRJ+wJDXvkgYPb1mK7j7dRU83aXQhPNL4snQOUXUlfv6X4MTULHIXEU
         suctiVWQE/VWjpAgGLrcmJXYBSFnrq1Q2DIf/E1yKVkh0CLrE8FuB6k3wM3FEfJluCI8
         qX/Oj15wle9RLBEtxBCSNfnYDuQ1fYw5pzGCM=
Message-ID: <4B2263FC.8090509@gmail.com>
Date: Fri, 11 Dec 2009 10:23:40 -0500
From: William Tam <email.wtam@gmail.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: users@cxf.apache.org
CC: users@camel.apache.org
Subject: Re: MTOM producer - different content-id in XOP:Include and MIME
 part 	for the same attachment?
References: <e68fd19f0912100739y4ce95190vdf5fd2780d6b7d48@mail.gmail.com>
 	<e68fd19f0912110148i31f52b35ndc323ef98ec43068@mail.gmail.com>
 	<e68fd19f0912110201h2c190755yf4c464d8a83633d9@mail.gmail.com>
 <e68fd19f0912110203s6613689bj9e9bcc5205288f40@mail.gmail.com>
In-Reply-To: <e68fd19f0912110203s6613689bj9e9bcc5205288f40@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


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 <mana.lists@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: <foo4%foo1@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 <mana.lists@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 <mana.lists@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
>>
>>     
>
>
>
>