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

[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