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 <sberyoz...@gmail.com>: > 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 >>> <sberyoz...@gmail.com>: >>> >>> 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="< >>>> root.mess...@cxf.apache.org >"; 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="< >>>> root.mess...@cxf.apache.org >"; 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/
