Description of problem: URL-encoded content ID for MTOM attachments causes problems with web service clients. This is effectively a regression on: https://issues.apache.org/jira/browse/CXF-2669 If the namespace is "https://cxf.apache.org/" then the content id is now: 5726d366-df25-4945-9f3b-3003a2ae8a70-3@http%3A%2F%2Fcxf.apache.org%2F It was previously: 5726d366-df25-4945-9f3b-3003a2ae8a70-3.org The url encoding can cause issues with some web service clients Version-Release number of selected component (if applicable): 2.7.16 How reproducible: Reliabily Steps to Reproduce: 1. Use MTOM with a namespace and inspect output. Actual results: Content Id contains the full namespace (as URL) which is URL encoded: 5726d366-df25-4945-9f3b-3003a2ae8a70-3@http%3A%2F%2Fcxf.apache.org%2F Expected results: Content id does not require encoding and only contains hostname: 5726d366-df25-4945-9f3b-3003a2ae8a70-3.org Additional info:
Hi, I have modified a MTOM integration test and tried to reproduce this issue with wireshark on https://github.com/soul2zimate/jboss-eap/commits/bz1245706-MTOM-Test-6.4.x . From wireshark capture, while sample image uploading and downloading, I noticed content ids are: Content-ID: <cea2a1cb-36cd-4465-91e9-b9172271d70f-1.org> Content-ID: <740fe340-2108-4b4a-af03-39a048357e99-1.org> I did not see mentioned encoded content "@http%3A%2F%2Fcxf.apache.org%2F" in my test, Could you help to share the way you reproduced it if you can see this in EAP 6.4.2? --uuid:a1c31987-dab4-43ce-b821-2e3f2a066555 Content-Type: application/xop+xml; charset=UTF-8; type="text/xml" Content-Transfer-Encoding: binary Content-ID: <root.message.org> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><ns2:downloadImageResponse xmlns:ns2="http://mtom.ws.integration.test.as.jboss.org/"><return><xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:cea2a1cb-36cd-4465-91e9-b9172271d70f-1@cxf.apache.org"/></return></ns2:downloadImageResponse></soap:Body></soap:Envelope> --uuid:a1c31987-dab4-43ce-b821-2e3f2a066555 Content-Type: image/png Content-Transfer-Encoding: binary Content-ID: <cea2a1cb-36cd-4465-91e9-b9172271d70f-1.org> ================================================================================ --uuid:d9317e68-4358-4a5d-8cd9-40fe6aa4e43e Content-Type: application/xop+xml; charset=UTF-8; type="text/xml" Content-Transfer-Encoding: binary Content-ID: <root.message.org> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><ns2:uploadImage xmlns:ns2="http://mtom.ws.integration.test.as.jboss.org/"><arg0><xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:740fe340-2108-4b4a-af03-39a048357e99-1@cxf.apache.org"/></arg0></ns2:uploadImage></soap:Body></soap:Envelope> --uuid:d9317e68-4358-4a5d-8cd9-40fe6aa4e43e Content-Type: image/png Content-Transfer-Encoding: binary Content-ID: <740fe340-2108-4b4a-af03-39a048357e99-1.org>
I am experiencing this problem as well. So far reproduced on EAP 6.3.3, 6.4.1, and 6.4.2. I have confirmed that it does not do this on 6.2.4. Any updates or workarounds? We are going to have to hold off on doing some JBoss upgrades until this is resolved, as it is breaking applications that consume the MTOM payloads (because the CID in the soap envelope doesn't match the Content-ID of the attachment). For some apps we have been able to work around the issue by running a URLDecode on the CID before attempting to retrieve the attachment, but this isn't an option for some of our applications.
I have checked that EAP 6.2.4 is on CXF 2.7.11.redhat-3. but the suspicious change in CXF-2669 is fixed since CXF 2.2.7. Could you share the reproducer you used ?
Created attachment 1068117 [details] Reproducer Reproducer. Includes a pre-built copy in mtomExample.war/dist/mtomExample.war. Or you can build with ant by setting JBOSS_HOME to a copy of JBoss .. doesn't work if cumulative patches are applied. Sorry!
I think the difference is the namespace on the @WebResult. If you run the reproducer I just attached what you should see is: --------------------------- ID: 14 Response-Code: 200 Encoding: UTF-8 Content-Type: multipart/related; type="application/xop+xml"; boundary="uuid:950ea810-e3aa-4dac-9b69-3231c4b53ee7"; start="<root.message.org>"; start-info="text/xml" Headers: {} Payload: --uuid:950ea810-e3aa-4dac-9b69-3231c4b53ee7 Content-Type: application/xop+xml; charset=UTF-8; type="text/xml" Content-Transfer-Encoding: binary Content-ID: <root.message.org> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><getAttachmentResponse xmlns="http://some.namespace.foo"><return><xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:92e035a0-d404-4573-a499-3b7b7161e95c-4@http%3A%2F%2Fsome.namespace.foo"/></return></getAttachmentResponse></soap:Body></soap:Envelope> --uuid:950ea810-e3aa-4dac-9b69-3231c4b53ee7 Content-Type: application/octet-stream Content-Transfer-Encoding: binary Content-ID: <92e035a0-d404-4573-a499-3b7b7161e95c-4@http://some.namespace.foo> test --uuid:950ea810-e3aa-4dac-9b69-3231c4b53ee7-- --------------------------------------
I confirmed that removing the @WebResult below gives the results you indicated. If you add a similar @WebResult to your test you should reproduce my results: @WebMethod @WebResult(targetNamespace = "http://some.namespace.foo") @XmlMimeType("application/octet-stream") public DataHandler getAttachment() {
In my case, I am doing contract first development starting with the WSDL and generating the interface code for the PortType. I have confirmed that the generated interface does have a non-empty targetNamespace on the @WebResult, but I haven't yet tracked down in my WSDL what is making that happen. So, I can't merely remove that value from my @WebResult, because it is generated from the WSDL. I'll try to post a contract-first example once I figure it out.
Created attachment 1068751 [details] top-down reproducer I am attaching a maven project here that reproduces this problem top/down. The project generates code from the wsdl as part of the generate-sources phase. A few of the 'provided' dependencies are sourced from a repository in house here, but they are just copies of the jboss artifacts in our in house nexus, so if you want to rebuild it you will need to update those dependencies. There is a mtom-sample.war in the target directory in the zip. Example request: ====== POST https://server.sppdev.org/MTOMService/v1 HTTP/1.1 Accept-Encoding: gzip,deflate Content-Type: text/xml;charset=UTF-8 SOAPAction: "http://mtom.domain/services/mtom/MTOMDataService/v1/GetSomeData" Content-Length: 304 Host: server.sppdev.org Connection: Keep-Alive User-Agent: Apache-HttpClient/4.1.1 (java 1.5) <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:v1="http://mtom.domain/schema/mtom/MTOMDataService/v1"> <soapenv:Header/> <soapenv:Body> <v1:GetSomeData> <v1:input>blah</v1:input> </v1:GetSomeData> </soapenv:Body> </soapenv:Envelope> ====== Example Response: ====== HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: multipart/related; type="application/xop+xml"; boundary="uuid:1086f68e-787a-47ce-8e89-220e91b864fa"; start="<root.message.org>"; start-info="text/xml" Content-Length: 945 Date: Mon, 31 Aug 2015 20:30:37 GMT --uuid:1086f68e-787a-47ce-8e89-220e91b864fa Content-Type: application/xop+xml; charset=UTF-8; type="text/xml" Content-Transfer-Encoding: binary Content-ID: <root.message.org> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><GetSomeDataResponse xmlns="http://mtom.domain/schema/mtom/MTOMDataService/v1"><SomeDataData><SomeDataArray><xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:a750773b-c314-40b3-8291-57628db34698-68@http%3A%2F%2Fmtom.domain%2Fschema%2Fmtom%2FMTOMDataService%2Fv1"/></SomeDataArray></SomeDataData></GetSomeDataResponse></soap:Body></soap:Envelope> --uuid:1086f68e-787a-47ce-8e89-220e91b864fa Content-Type: application/octet-stream Content-Transfer-Encoding: binary Content-ID: <a750773b-c314-40b3-8291-57628db34698-68@http://mtom.domain/schema/mtom/MTOMDataService/v1> ‹ ====== Notice the end part of the CID is now a URL that gets URL Encoded in the soap body, making it not match the actual Content-ID of the attachment. I confirmed that the generated MTOMDataServicePortType.java (included in the zip) includes this annotation: @WebResult(name = "SomeDataData", targetNamespace = "http://mtom.domain/schema/mtom/MTOMDataService/v1") So I think this is the same issue as described in the previous reproducer, just a different way to get to the same behavior. On JBoss 6.2.x, the CID was always just the hostname portion of the namespace.
At this point I would like to know if there is some way in my project (referencing the top-down reproducer attachment) that I can get back to the old CID behavior, or similar. At least something that is not URL Encoded. Changing the WSDL/XSD is not an option but changing the way the project generates stub code or anything else to do with the project is fair game. I have clients that call my service that I don't control, so I need a way that I can resolve this before I can upgrade JBoss. Thanks
Verified with 6.4.6.CP.CR2
Retroactively bulk-closing issues from released EAP 6.4 cumulative patches.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days