I am using AXIS 1.2 alpha and Tomcat 5.0.3 and a .net application has been able to access the atachment I send. They were initially having problems until they installed the Web services enhancements service pack.
Regards Jim. ----- Original Message ----- From: "sergeant" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 22, 2004 3:52 PM Subject: RE: Attachment from Axis service causing .NET to Error > 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. > >
