URL-encoded content ID for MTOM attachments causes problems with web service clients

Solution Verified - Updated 2016-01-21T23:21:21+00:00 -

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:

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 ?

A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.