Hi Aki, Sergey, thank you very much guys. I have enough information now. The way we will solve our problem is clear now, despite the fact, that this way is a most difficult one, we have to convince our integration partners to switch to newer version of CXF. But information from contributors will help us a lot.
Again many thanks for your encouragement and your fast reaction. Well done! Regards, Dmitri > Am 16.01.2017 um 12:53 schrieb Aki Yoshida <[email protected]>: > > forgot to refer to this link as well > https://www.w3.org/TR/2005/REC-xop10-20050125/#example > > > 2017-01-16 12:45 GMT+01:00 Aki Yoshida <[email protected]>: >> Hi Dmitri, Sergey, >> I read what I wrote in CXF-6431. >> >> As far as I remember, the relevant change regarding the action value >> is derived from the MTOM spec, in particular, in the following section >> https://www.w3.org/TR/2005/REC-xop10-20050125/#identifying_xop_documents >> >> The above section specifies how the start-info of the package header >> and the type header of the root content must look. RFC2387 is >> referenced in CXF-6431 about the type parameter of the package header >> and not about the type parameter of the root content. >> >> So, I don't know what exactly is talked about here. >> >> regards, aki >> >> 2017-01-13 14:05 GMT+01:00 Sergey Beryozkin <[email protected]>: >>> Hi Dmitri, lets ask Aki >>> >>> Hi Aki, do you remember why did you enforce it according to RFC2387, was >>> there some SOAP server which was expecting an RFC2387 compliant 'type' with >>> an 'action' being a type's property as opposed to it being a SOAP part's >>> Content-Type property as in the older CXF versions ? >>> >>> Thanks, Sergey >>> >>> >>> >>> On 13/01/17 08:26, Dmitri Zamyslov wrote: >>>> >>>> Hi Sergey, >>>> >>>> we analysed thoughrowly the issue and we came to the same conclusion, that >>>> the 'action' some how not a content type parameter, but mentioned (escaped) >>>> in start-info parameter as part of the type of the main SOAP message part >>>> in >>>> compound structure. >>>> >>>> SOAP with Attachment described in W3C as a feature and the regulatory >>>> document shows the principles of how the compound structure have to be >>>> built. But there is no proper info how it shall be practically implemented. >>>> >>>> In CXF implementation in AttachmentSerializer class the implementer >>>> references https://tools.ietf.org/html/rfc2387 . But this RFC describes >>>> only multipart/related content type. There is no dedicated information >>>> about SOAP. >>>> >>>> We compared behaviour of CXF 3.1.6 with SOAP UI (which we use as a test >>>> tool). SOAP UI uses open-ws and the produced SOAP package looks like from >>>> older CXF version, means it has 'action' as a property of the main >>>> content-type header (proper way). >>>> >>>> We have seen also the issue in CXF in version 2, which was fixed before >>>> 2.7.13, and it seems to be almost the same problem. >>>> >>>> So I am looking forward to get a response from CXF team. We really need to >>>> know is it an issue and will be fixed soon, or it is a change in handling >>>> according to some regulations - then we will have to take other steps. >>>> >>>> Regards, >>>> Dmitri >>>> >>>> >>>>> Четверг, 12 января 2017, 19:17 +01:00 от Sergey Beryozkin >>>>> <[email protected]>: >>>>> >>>>> Hi >>>>> >>>>> This change introduced an escaping for the 'action': >>>>> >>>>> >>>>> https://github.com/apache/cxf/commit/9bbf1acd7291416f9afcd312e7dc302e9031fa25#diff-230a76e41a0370126d1e6e2ea28728eeR170 >>>>> >>>>> but also in the 2nd Content-Type it is >>>>> >>>>> type="application/soap+xml; >>>>> >>>>> Note no closing double quote. >>>>> >>>>> Effectively, the type is >>>>> >>>>> type="application/soap+xml; >>>>> action=\"urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b\"" >>>>> >>>>> where 'action' is a property of the application/soap+xml media type. >>>>> >>>>> I'm not sure how SOAP w Att compliant it is, just trying to reason why >>>>> this change was made... >>>>> >>>>> Thanks, Sergey >>>>> >>>>> >>>>> >>>>> On 12/01/17 15:31, Dmitri Zamyslov wrote: >>>>>> >>>>>> Dear Contributors, >>>>>> >>>>>> during preparation for the migration from Wildfly 8 to 10 we have >>>>>> detected a change of CXF behaviour for handling of SOAP with Attachment - >>>>>> multipart/related, which caused problems during integration tests. >>>>>> Wildfly 8 >>>>>> uses CXF version 2.7.13, Wildly 10 - 3.1.6. The causing difference code >>>>>> is >>>>>> located in org.apache.cxf.attachment.AttachmentSerializer and leads to >>>>>> different content-type headers: >>>>>> >>>>>> in Wildfly 8 by sending of SOAP with Attachments: >>>>>> >>>>>> main content-type header: >>>>>> Content-Type: multipart/related; type="application/xop+xml"; >>>>>> boundary="uuid:fba1c798-9dc4-4f87-b6a5-dc7534553c80"; start="< >>>>>> [email protected] >"; start-info="application/soap+xml"; >>>>>> action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b" >>>>>> >>>>>> content-type header of SOAP part >>>>>> Content-Type: application/xop+xml; charset=UTF-8; >>>>>> type="application/soap+xml"; >>>>>> action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b" >>>>>> >>>>>> in Wildfly 10: >>>>>> >>>>>> main content-type header: >>>>>> Content-Type: multipart/related; type="application/xop+xml"; >>>>>> boundary="uuid:e88e47bb-1abe-4362-b1a4-57a8d9e027dc"; start="< >>>>>> [email protected] >"; start-info="application/soap+xml; >>>>>> action=\"urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b\"" >>>>>> >>>>>> content-type header of SOAP part: >>>>>> Content-Type: application/xop+xml; charset=UTF-8; >>>>>> type="application/soap+xml; >>>>>> action=\"urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b\"" >>>>>> >>>>>> There are no other significant differences in HTTP POST messages. >>>>>> >>>>>> As you can see difference is in the escaped action in content-type >>>>>> header, which now is a part of start-info parameter. Because of this >>>>>> difference we getting failure from our integration partner: "A header >>>>>> representing a Message Addressing Property is not valid and the message >>>>>> can >>>>>> not be processed". >>>>>> >>>>>> Dear contributors, can you please let me know if this change was done by >>>>>> failure or it is a right way of handling. If it is a right way please >>>>>> let me >>>>>> know which standards describe this behaviour. Thank you very much in >>>>>> advance. >>>>>> >>>>>> Regards. >>>>>> >>>>> >>>>> >>>>> -- >>>>> Sergey Beryozkin >>>>> >>>>> Talend Community Coders >>>>> http://coders.talend.com/ >>>> >>>> >>> >>> >>> -- >>> Sergey Beryozkin >>> >>> Talend Community Coders >>> http://coders.talend.com/
