axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Rineholt" <rineh...@us.ibm.com>
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. :-(

>Rick-
>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.
>Thanks
>-Jason Blumenkrantz
>jason.blumenkrantz@tfn.com
>Error Trace:
>(100)Continue
>at
>org.apache.axis.transport.http.HTTPSender.readFromSocket(HTTPSender.j
>ava:536)
>at
>org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:135)
>at
>org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrateg
>y.java:71)
>at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:150)
>at org.apache.axis.SimpleChain.invoke(SimpleChain.java:120)
>at org.apache.axis.client.AxisClient.invoke(AxisClient.java:183)
>at org.apache.axis.client.Call.invokeEngine(Call.java:2075)
>at org.apache.axis.client.Call.invoke(Call.java:2064)
>at org.apache.axis.client.Call.invoke(Call.java:1834)
>at org.apache.axis.client.Call.invoke(Call.java:1759)
>at org.apache.axis.client.Call.invoke(Call.java:1299)
>at
>worldstreet.soapclient.ContentHandler.addContentItem(ContentHandler.j
>ava:288)
>at worldstreet.soapclient.test.ContentTest.main(ContentTest.java:65)
>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 [mailto:rineholt@us.ibm.com]
>Sent: Tuesday, June 18, 2002 5:39 PM
>To: axis-dev@xml.apache.org
>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:
>call.setScopedProperty(MessageContext.HTTP_TRANSPORT_VERSION,HTTPConstants.H

>EADER_PROTOCOL_V11);
>Hashtable myhttp= new Hashtable();
>myhttp.put(HTTPConstants.HEADER_TRANSFER_ENCODING,HTTPConstants.HEADER_TRANS

>FER_ENCODING_CHUNKED);
>call.setScopedProperty(HTTPConstants.REQUEST_HEADERS,myhttp);
>then use the call object to send the attachments.
>The server should also send the data back without reading the handlers
>twice.
>I need to add support for servlet engines that don't chunk and some other
>refinements.
>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
>heavily.
>
>Rick Rineholt
>"The truth is out there...  All you need is a better search engine!"
>rineholt@us.ibm.com
>
>"Blumenkrantz, Jason" <Jason.Blumenkrantz@tfn.com> on 04/05/2002 03:35:00
>PM
>Please respond to axis-dev@xml.apache.org
>To:    "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
>cc:
>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?
>Thanks
>-Jason
>-----Original Message-----
>From: Ng, Charles [mailto:Charles.Ng@cognos.com]
>Sent: Wednesday, April 03, 2002 11:42 AM
>To: 'axis-dev@xml.apache.org'
>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.
>Charles
>-----Original Message-----
>From: Blumenkrantz, Jason [mailto:Jason.Blumenkrantz@tfn.com]
>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
>be
>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?
>Thanks,
>Jason Blumenkrantz
>jason.blumenkrantz@tfn.com
>This message may contain privileged and/or confidential information.  If
>you
>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!"

rineholt@us.ibm.com


Mime
View raw message