Re: SOAP w. Att. Content-type header, action parameter issue
Hi Aki, Sergey, thank you very much guys. I have enough information now. The way we will solve our problem is clear now, despite the fact, that this way is a most difficult one, we have to convince our integration partners to switch to newer version of CXF. But information from contributors will help us a lot. Again many thanks for your encouragement and your fast reaction. Well done! Regards, Dmitri > Am 16.01.2017 um 12:53 schrieb Aki Yoshida : > > 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 : >> 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 : >>> 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 > : > > 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 >> Conte
Re: SOAP w. Att. Content-type header, action parameter issue
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 : > 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 : >> 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 : 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:
Re: SOAP w. Att. Content-type header, action parameter issue
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 : > 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 >>> : >>> >>> 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 >
Re: SOAP w. Att. Content-type header, action parameter issue
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 : 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/
Re: SOAP w. Att. Content-type header, action parameter issue
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/
