URL-encoded content ID for MTOM attachments causes problems with web service clients
Issue
-
After updating from EAP 6.2.3 to 6.3.3, we noticed that the content-id that is generated for MTOM attachments returned by our web service has changed. It now additionally contains the
http://prefix to the namespace. -
This change causes problems with certain web service clients that do not take into account that the content-id in the SOAP body is URL-encoded ("...@http%3A%2F%2F...") , whereas the following content-id MIME header is written like
...http://.... -
A concrete example is SoapUI 5.0.0, which fails to expand the MTOM attachment prior to schema validation (and as a result, reports a schema compliance violation).
The issue is similar to this, https://issues.apache.org/jira/browse/CXF-2669.
The probable commit responsible for this change in behavior is the following:
https://github.com/apache/cxf/commit/5f89d20234c3786d354f8ab1f2b4ee1f9a421490.
- We have a great number of web service clients using different technologies and do not want to risk breaking compatibility with existing services. Is it possible to override the content-id without using a performance-degrading handler/interceptor, and without having to redesign our JAX-WS-centered web service code ?
Environment
- Red Hat JBoss Enterprise Application Platform (EAP)
- 6.3.3
- JBossWS-CXF
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
