axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Blumenkrantz, Jason" <>
Subject RE: Bug in attachment handling / MimeUtils
Date Tue, 16 Jul 2002 21:40:22 GMT
I just gave this a try with the current CVS tree. I'm attempting to send an
InputStream from client to server, and I've been using HTTP 1.1 in the
server since this fix, but I just added the chunking to the client (by
switching from FileDataSource to a DataSource backed by a live input
stream). I'm using Jetty as the HTTP server, and am unfortunately not having
much luck on the client side, since HTTPSender seems unable to handle a
100:Continue status response (The server seems to have handled the
uploadeded file just file). Any idea how HTTPSender can be fixed quickly to
support Continue? If this isn't something you could take care of easily, I
have a few spare cycles if you could offer an approach. Below is the error
stack trace and the HTTP response headers.
-Jason Blumenkrantz

Error Trace:

        at org.apache.axis.SimpleChain.doVisiting(
        at org.apache.axis.SimpleChain.invoke(
        at org.apache.axis.client.AxisClient.invoke(
        at org.apache.axis.client.Call.invokeEngine(
        at org.apache.axis.client.Call.invoke(
        at org.apache.axis.client.Call.invoke(
        at org.apache.axis.client.Call.invoke(
        at org.apache.axis.client.Call.invoke(
        at worldstreet.soapclient.test.ContentTest.main(

HTTP Header Trace:
HTTP/1.1 100 Continue

HTTP/1.1 200 OK
Date: Tue, 16 Jul 2002 21:34:34 GMT
Server: Jetty/4.0.4 (Windows 2000 5.0 x86)
Servlet-Engine: Jetty/1.1 (Servlet 2.3; JSP 1.2; java 1.4.0)
Connection: close
Content-Type: text/xml; charset=utf-8

-----Original Message-----
From: Rick Rineholt []
Sent: Tuesday, June 18, 2002 5:39 PM
Subject: RE: Bug in attachment handling / MimeUtils

There "might" be a fix for this now in Axis  but its really still just
"work in progress".    I did try and test it out for tomcat 4.03
 with chunking  enabled (that should be the default).  On the client side
to avoid the reading of the attachment data twice do:

Hashtable myhttp= new Hashtable();

then use the call object to send the attachments.

The server should also send the data back without reading the handlers

I need to add support for servlet engines that don't chunk and some other

For the client side I strongly suggest you only do this for the attachment
calls and revert back to HTTP 1.0 since it probably hasn't been tested to

Rick Rineholt
"The truth is out there...  All you need is a better search engine!"

"Blumenkrantz, Jason" <> on 04/05/2002 03:35:00

Please respond to

To:    "''" <>
Subject:    RE: Bug in attachment handling / MimeUtils

I realize that it isn't a great solution, and doesn't work in all
environments, but the current way of reading from the input stream twice
won't work in any environments. Any ideas for the right way to handle this?


-----Original Message-----
From: Ng, Charles []
Sent: Wednesday, April 03, 2002 11:42 AM
To: ''
Subject: RE: Bug in attachment handling / MimeUtils

This makes the assumption that the servlet container will do HTTP chunking
for you.  I know Tomcat 3.2 does not.


-----Original Message-----
From: Blumenkrantz, Jason []
Sent: Wednesday, April 03, 2002 10:31 AM
To: Axis-Dev (E-mail)
Subject: Bug in attachment handling / MimeUtils

I'm having a problem returning Attachments via Axis using the
JAFDataHandlerSerializer and org.apache.axis.attachments.MimeUtils. The
DataHandler is being returned fine and added as an attachment, but the
content's mime part ends up empty. The problem seems to be in
MimeUtils.getContentLength(), where if the DataSouce is not a file
DataSource, the input stream is read in completely to determine the content
length. Since my service returns a live InputStream and not a File, the
stream is invalidated by the reading process.  So not only is the stream
read entirely into memory, but the attachment data is never being written
out to the client. The two possible solutions I see to this problem would
to keep the in-memory buffer around and write that out instead of
incorrectly reusing the InputStream (which is suboptimal, since this
requires the entire stream to be read into memory), or in the case of MIME
attachments which are not file attachments, to not write back the content
length in the response at all. I've modified a copy of AxisServlet to never
write the content length in this case, and it seems to work fine with both
Axis and VS.NET clients. Anyone have ideas on the best way to fix the
current incorrect behavior?

Jason Blumenkrantz

This message may contain privileged and/or confidential information.  If
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.  Thank you.

View raw message