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.


Четверг, 12 января 2017, 19:17 +01:00 от Sergey Beryozkin 


This change introduced an escaping for the 'action':


but also in the 2nd Content-Type it is


Note no closing double quote.

Effectively, the type is


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"; 

content-type header of SOAP part
Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml"; 

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; 

content-type header of SOAP part:
Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml; 

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.


Sergey Beryozkin

Talend Community Coders

Sergey Beryozkin

Talend Community Coders

Reply via email to