tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Filip Hanik" <m...@filip.net>
Subject RE: inputstream
Date Mon, 30 Apr 2001 18:04:10 GMT
>I fought with this for a very long time.
>It was difficult, I found examples but none of them worked.
>In the end I had to resort to perl.

did you take a look at the O'reilly servlet examples. they include full
source code for doing this in a working example

Filip

~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
filip@filip.net
www.filip.net
-----Original Message-----
From: Allen Levin [mailto:allenrlevin@hotmail.com]
Sent: Monday, April 30, 2001 10:14 AM
To: tomcat-user@jakarta.apache.org
Subject: Re: inputstream


I fought with this for a very long time. It was difficult, I found examples
but none of them worked. In the end I had to resort to perl.
There are definately area within Java/JSP/Tomcat that are not working well.
This is one of them.


From: Tim O'Neil
Reply-To: tomcat-user@jakarta.apache.org
To: tomcat-user@jakarta.apache.org
Subject: Re: inputstream
Date: Mon, 30 Apr 2001 09:29:08 -0700
At 11:51 AM 4/30/2001 -0400, you wrote:
>hi everyone,
>
>i'm trying to use a form to upload a file from the webpage to my
>server.
>
>i don't want to store the file on myserver, i just want to receive
>the file
>data and send it somewhere else right away.
>
>i know that i have to parse the received data to eliminate the
>boundaries
>and th content type,etc.
>
>do you know the max size that i can receive on the
>standardInputStream????????
Being a stream that's a loaded question, although
reading the api policy on the DataInput interface
I presume its the maximum size of a byte array.
But this is the wrong way to look at an inputstream.
The input data has to go somewhere, right? I would
assume also that your going to write the input into
an output stream, so theoretically you'll not need to
worry about a limit. Presumably the data is going somewhere
as soon as it comes in. What you really need to worry
about is the other end, the data receiver might choke,
go off line, slow down, stop receiving for whatever reason.
You should plan for that in your design, and implement
a temporary buffer on your transmitting end.



Get your FREE download of MSN Explorer at http://explorer.msn.com


Mime
View raw message