Malformed Content-Id in SOAP Attachment Response?

[gregcrider]

I have a JSE web service that returns a DataHandler. The client side throws an exception saying it can't find the Content-Id specified in the SOAP response. Using ethereal, I captured the entire response, and can clearly see the attachment, however, there does appear to be a problem with the Content-Id in the MIME portion. Here is the SOAP response I get back from JBoss AS 4.0.1:


HTTP/1.1 200 OK
X-Powered-By: Servlet 2.4; Tomcat-5.0.28/JBoss-4.0.1 (build: CVSTag=JBoss_4_0_1 date=200412230944)
Content-Type: multipart/related; type="text/xml"; start="<AEF4379B67A42412258E335FA85EE750>"; boundary="----=_Part_13_24567153.1106763566149"
Transfer-Encoding: chunked
Date: Wed, 26 Jan 2005 18:19:26 GMT
Server: Apache-Coyote/1.1

2cb

------=_Part_13_24567153.1106763566149
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: binary
Content-Id: <AEF4379B67A42412258E335FA85EE750>

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<ns1:downloadResponse xmlns:ns1="urn:server.transport.rbu.edc.com/ServerFile">
<result href="cid:A9FCB00186FA6E4FFC4DB12F3B36CAFB" xmlns:ns2="http://java.sun.com/jax-rpc-ri/internal"/>
</ns1:downloadResponse>
</soapenv:Body>
</soapenv:Envelope>
2000

------=_Part_13_24567153.1106763566149
Content-Type: text/html
Content-Transfer-Encoding: binary
Content-Id: <A9FCB00186FA6E4FFC4DB12F3B36CAFB>

.... attached file removed by poster for clarity ...

------=_Part_13_24567153.1106763566149--

0

In the SOAP envelope, you can see "cid:A9FCB00186FA6E4FFC4DB12F3B36CAFB", but in the MIME portion where the attachment lives, the Content-Id is wrapped with < and >. I think this is causing the exception in my client.

Any thoughts?

[anil.saldhana]

http://jira.jboss.com/jira/browse/JBWS

Can you file a bug with a testcase in the JIRA? Can you attach a test war to speed up investigation and fix (if any)?

[gregcrider]

I created the defect as you requested. It is JBWS-81. I attached a number of files from my original web service. In addition, as requested, I created a simple test web service that generates the same error condition.

[avinashi]

I am facing the same problem. The client is not able to parse the return message.

[thomas.diesler]

Is this of any help
http://www.jboss.org/wiki/Wiki.jsp?page=WSAttachments

[jason.greene]

"gregcrider" wrote:

In the SOAP envelope, you can see "cid:A9FCB00186FA6E4FFC4DB12F3B36CAFB", but in the MIME portion where the attachment lives, the Content-Id is wrapped with < and >. I think this is causing the exception in my client.

Any thoughts?

FYI, This is how cid locators are constructed per the MIME multipart/related RFC. The header always includes <>'s the url doesn't.

-Jason

[gregcrider]

That's interesting. I have another method where I upload a file as DataHandler argument. The client code runs with the Sun J2EE 1.4 jar files, and does not wrap the id with < and >. That was the basis for my assuming the JBoss AS 4.0.1 was messing up.

For the original problem pointed out by this thread, I am using the same Sun J2EE 1.4 jar files for my client. After searching the Sun forums, I didn't see any mention of a bug existing that pertains to the locator id.

When I run my client that invokes my upload web service (which doesn't wrap with < and >), JBoss AS 4.0.1 is able to locate the attachment.

For the defect that I was asked to open up (JBWS81), I created a simple test case as requested. With this test code, an HTML file was to be downloaded, but it exhibited the same problem that I am experiencing with my other code.

I have exhausted all of the resources that I can think of at the moment. An earlier post about the Attachment Wiki didn't help either.

[thomas.diesler]

http://jira.jboss.com/jira/browse/JBWS-81

[gregcrider]

Thomas, I see that JBWS-81 was closed out because it doesn't conform to the Jax-RPC 1.1 spec according to your notes.

If this is the case, why can I use a DataHandler as a method argument (which works fine), but I can't use a DataHandler as a return type? For the case of the DataHandler as the return type, JBoss-WS is creating the attachment and sending it back, but my client code can't locate it. Does this indicate that something can be done on the client side to work around this without have to resort to a pure SAAJ SOAP implementation of my code?

[thomas.diesler]

That it works as a parameter might be a side effect of some implementation detail, it is not supported or required by the spec.

The important question is: What is preventing you from doing attachments that are spec compliant?

[gregcrider]

I looked more closely at the JAX-RPC 1.1 spec as you suggested. In an effort to be compliant, I changed my return type to be MimeMultipart instead of DataHandler. In my server-side method, I add a client requested file (specified by the client as a String file name) to the MimeMultipart object. This is essentially what my code looks like:

MimeMultipart result = null ;
File file = new File( a_Filename ) ;

try {
result = new MimeMultipart() ;
MimeBodyPart mbp = new MimeBodyPart() ;
mbp.setDataHandler( new DataHandler( new FileDataSource( file ) ) ) ;
result.addBodyPart( mbp ) ;
} catch ( Exception e ) {
}

return result ;

This code generates the same error as before when I simply returned a DataHandler (it can't find the SOAP attachment, even though it is there). I also tried to manually set my own content id on the MimeBodyPart, but that didn't help, because the client can't locate the SOAP attachment.

I'm getting frustrated in my effort to make this work. I'd love to see a working example of this (returning an attached file). The JBoss WS test suite is not much help, because the examples show how to pass in MimeMultipart arguments, and not return them. Also, it uses the Axis java2wsdl, instead of wscompile. I was first using java2wsdl, but that seemed to create its own set of problems. From reading this forum, it appeared that people felt that wscompile was the better way to go.

[thomas.diesler]

I reoped the case. You are right the testsuite does not check if we can actually return attachements to the client as well.

http://jira.jboss.com/jira/browse/JBWS-81

[gregcrider]

Thanks Thomas. I appreciate your patience with me on this topic.

[thomas.diesler]

Man, you are the hero on this.

[gregcrider]

I rewrote my web service as a SAAJ servlet. The client in this case had the same problem as the original web service. The cid attachment id is returned with enclosing < >. In order for my client to be able to locate the attachment, I had to add the characters to the "Content-Id" MIME header used to locate the attachment:

MimeHeaders headers = new MimeHeaders() ;
SOAPElement file = (SOAPElement)iter.next() ;
String ref = file.getAttributeValue( soapFactory.createName( "href" ) ) ;
ref = ref.substring( 4 ) ;
headers.setHeader( "Content-Id", "<" + ref + ">" ) ;
Iterator attachmentIter = reply.getAttachments( headers ) ;

where reply is the SOAPMessage response from the SAAJ servlet.

I wrote a new web service that returns a javax.xml.transform.Source object which is supposed to be valid for the JAX-RPC spec. The client code in this case can't find the attachment for the same reason.