-----------------------------
Please read the FAQ!
<http://java.apache.org/faq/>
-----------------------------
Solomon Douglas wrote:
> -----------------------------
> Please read the FAQ!
> <http://java.apache.org/faq/>
> -----------------------------
>
> Craig -
>
> Since my request is of type multipart/form-data, what you said
> guarantees that the input stream hasn't been touched. So, I tried:
>
> request.getInputStream().skip(request.getContentLength());
>
> This does the job for me. Now I'm getting all the output to my
> browser that I expected. Yay! Thanks everybody for your help.
>
Glad to hear this worked ... but ... you can still get bit by one
scenario. If the originating client does not include a content length,
the getContentLength() call will return -1. In that case, according to
the description of InputStream.skip(), no bytes will be skipped -- and
your output will mysteriously disappear again.
I would suggest testing for this condition and, if you get -1 back,
physically read the input stream until you get an end-of-file indication
back.
But, you might say, the browser *always* sets the content length on file
uploads! Well, who's to say that future versions won't have a bug? Or
that the client might actually be an application or an applet, rather
than a browser?
There's an old cliche related to Internet protocol implementations -- "be
liberal in what you accept, but strict in what you generate". This is
one of those cases where it's easy to deal robustly with clients that are
broken.
>
> (So, this does mean that the servlet cannot sent output to the
> response before it's done reading the request, as someone suggested.)
>
> I'm thinking I should use readLine() instead of skip(). The
> ServletInputStream.skip() method is inherited from InputStream, whose
> documentation says that skip() is inefficient and should be
> overridden. ServletInputStream does not override skip(), but it does
> provide readLine() which is said to be "efficient". Also, I presume
> that the value returned by getContentLength may be inaccurate, since
> it comes from the request headers rather than reflecting the actual
> content. If I repeatedly call readLine() until it returns -1, I'm
> guessing that'll be faster and more reliable, but I can't readily test
> those guesses...
>
I would be surprised if it makes enough difference to matter, but if you
are really going to read instead of skip (which you have to do in order
to deal with the content length not being available, as above), it would
probably save a few picoseconds to just throw a buffered input stream
around it, and read bytes in a tight loop until you get EOF. There's no
reason to pay the overhead of determining line endings that readLine
implies, since you are ignoring it all anyway.
But it is pretty unlikely that the difference between approaches is
significant. And, after all, doesn't this whole issue of ignoring the
input file happen in one of your "it won't really happen, but just in
case" scenarios anyway?
> Solomon
Craig
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
