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/
