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/
