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/
