axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Rineholt" <>
Subject Re: RE: Bug in attachment handling / MimeUtils
Date Wed, 17 Jul 2002 14:30:44 GMT
Sorry, (not an HTTP guru) My understanding was that the server would never
send that UNLESS the http client sent a HTTP "Expect " header with
Continue-100 val.
Looking at the spec last night, it explicitly mentions it might :-(.
I have a solution in mind, (partially  hacked up).  But I  wouldn't
probably be able
to get it in till earliest,  early next week. :-(

>I just gave this a try with the current CVS tree. I'm attempting to send
>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
>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
>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
>-----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
>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
>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.

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

View raw message