Bug 1245706 - [GSS] (6.4.z) URL-encoded content ID for MTOM attachments causes problems with web service clients
Summary: [GSS] (6.4.z) URL-encoded content ID for MTOM attachments causes problems wit...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web Services
Version: 6.3.3
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: CR1
: EAP 6.4.6
Assignee: Chao Wang
QA Contact: Rostislav Svoboda
URL:
Whiteboard:
Depends On:
Blocks: 1235746 1275205
TreeView+ depends on / blocked
 
Reported: 2015-07-22 14:41 UTC by Chris Dolphy
Modified: 2023-09-14 03:02 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-17 11:46:17 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Reproducer (14.04 KB, application/zip)
2015-08-28 18:43 UTC, Chris Dolphy
no flags Details
top-down reproducer (78.14 KB, application/zip)
2015-08-31 20:39 UTC, Eric Wyles
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Apache JIRA CXF-6484 0 None None None Never
Apache JIRA CXF-6517 0 None None None Never
Red Hat Knowledge Base (Solution) 2062163 0 None None None 2016-01-21 23:14:04 UTC

Description Chris Dolphy 2015-07-22 14:41:46 UTC
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:

Comment 1 Chao Wang 2015-07-23 10:07:04 UTC
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>

Comment 2 Eric Wyles 2015-08-25 21:49:26 UTC
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.

Comment 3 Chao Wang 2015-08-26 04:41:49 UTC
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 ?

Comment 4 Chris Dolphy 2015-08-28 18:43:52 UTC
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!

Comment 5 Chris Dolphy 2015-08-28 18:51:33 UTC
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--
--------------------------------------

Comment 6 Chris Dolphy 2015-08-28 18:55:02 UTC
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() {

Comment 7 Eric Wyles 2015-08-28 19:03:34 UTC
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.

Comment 9 Eric Wyles 2015-08-31 20:39:11 UTC
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.

Comment 10 Eric Wyles 2015-08-31 20:41:16 UTC
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

Comment 16 Jan Blizňák 2016-01-21 11:59:11 UTC
Verified with 6.4.6.CP.CR2

Comment 17 Petr Penicka 2017-01-17 11:46:17 UTC
Retroactively bulk-closing issues from released EAP 6.4 cumulative patches.

Comment 18 Petr Penicka 2017-01-17 11:47:42 UTC
Retroactively bulk-closing issues from released EAP 6.4 cumulative patches.

Comment 19 Red Hat Bugzilla 2023-09-14 03:02:26 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


Note You need to log in before you can comment on or make changes to this bug.