Yes, I'm using WSE10SP1. Uploading an attachment works fine, downloading from Axis on tomcat 4.1.29 fails with the message indicated below.
Here I'm talking about the HTTP Content-Type header. This must be 'application/dime' when sending attachments to a .NET client, rather than 'multipart/related'. At least that is my understanding based on reading, and viewing SOAP conversations on the wire between .NET services and clients. It is also what Axis uses when you set the send type like this: messageAttachments.setSendType(Attachments.SEND_TYPE_DIME); After tracking this down the only issue I can see is the addition of the unnecessary ';charset=ISO-8859-1' by tomcat 1.4.29. I could be wrong about this, but it does seem to match the error messages and other evidence. What servlet engine and version are you using? Thanks for the response. --Brad -----Original Message----- From: Abhinav Maheshwari [mailto:[EMAIL PROTECTED] Sent: Monday, March 22, 2004 4:06 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Attachment from Axis service causing .NET to Error Hi Sergeant, Do you have the Web Service Enhancements 1.0 with Service Pack 1 installed on your Visual Studio ? This is necessary to handle attachments on the .NET client. In my opinion, the problem is not due to charset but the content type 'application/dime'. In case, this does not resolve your problem, I will mail again with detailed steps. Seems like many users are having problems with attachments. Warm regards, Abhinav Maheshwari -----Original Message----- From: sergeant [mailto:[EMAIL PROTECTED] Sent: Saturday, March 20, 2004 8:44 AM To: [EMAIL PROTECTED] Subject: Attachment from Axis service causing .NET to Error BACKGROUND: I'm using Axis 1.1 on Tomcat 4.1.29. I've written a WSDL using a simple document/literal approach and am interoperating with both Axis and .NET clients. I've introduced an operation that returns a binary attachment and this works fine with the Axis client. The WSDL knows nothing of the attachment, (using the approach suggested by the Axis attachment FAQ), except that I am using a SOAP Header to indicate whether to use DIME or not. PROBLEM: The C# .NET client fails with the following error message when it receives the response: "Client found response content type of 'application/dime;charset=ISO-8859-1', but expected 'text/xml'." Using tcpmon I verified that the following was being sent from the service: Content-Type: application/dime;charset=ISO-8859-1 DETAILS: It appears to me that the addition of the ";charset=ISO-8859-1" is causing the problem. Monitoring communication between .NET client/Server shows they expect just "application/dime" and no charset. From the AxisServlet code it is clear to me that Axis is doing the right thing. The problem is that Tomcat is forcing the ";charset=..." to be added when HttpServletResponse.setContentType() is called. I have been able to change it to "application/dime;charset=utf-8", but that did not fix the interop problem. QUESTION: Anyone run into this? Anyone using a different version of Tomcat or another Servlet engine that they know avoids this problem? CHOICES: My next path is to either get a different servlet engine or to download the source to Tomcat and fix it myself. Any other suggestions? Thanks for any help. --Brad Sergeant SIDE COMMENT: I've been enjoying using Axis and feel the development environment is efficient, using Ant to generate the client and server stubs, compile, deploy, and reload axis makes turnaround very fast. Trick seems to be to get the WSDL right for interop.
