Phil Swenson wrote:
>
> Has anyone dealt with stopping posts on ulta-low speed uploads?
Yes, someone recently investigated how this works. The difficulty is
that HTTP (far as I know) requires the client finish the request before
the server can respond. So there's not much you can do on the server
side to cancel, short of try to convince the server to disconnect, which
gives the client a mysterious error.
Should the server really do the disconnect though? When there's a slow
upload, isn't it up to the client to decide to cancel? In that case
they can just hit STOP and the server will catch the disconnect and go
on.
> does the class deal with the post being cancelled in the
> middle well?
As well as any class can. The class lets you have a limit for max
upload size, so you can error out early if it exceeds your
requirements. This opens another can of worms about how to tell
the client about the problem. Basically it seems you have to eat the
request if you want to generate a real error page.
See the attached for one person's experience. If anyone knows more on
this, pipe up.
Subject: Tomcat handling of large form-data requests
Date: Thu, 20 Jan 2000 10:32:59 -0800
From: "James, Barnaby" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
Hi,
I've been developing a servlet that handles file uploads using a
multipart/form-data request. On the servlet side, there is a limit on
the
size of request that it will handle (I'm using Jason Hunter's
super-useful
MultipartRequest class) and the idea is that an error page would be
produced
if the post is too large. Under JRun, it look like the servlet engine
cannot
interrupt the client so the client sends all the data and then gets the
response page indicating the problem. It would be nice if I could
interrupt
the client in the middle of processing but it seems like this won't fly.
In Tomcat 3.1 (Jan 18th build), the behaviour is different. Under IE 5.0
the
client gets a "Server not found" page and under Netscape, the client
puts up
a "Connect reset by peer" dialog. In any event, it looks like, since my
servlet never reads the input stream and sends the response page, the
client
gets an error because the connection gets reset. I would guess that JRun
finishes reading the input stream if the Servlet doesn't.
Now the question is, which behaviour is correct? Is my servlet on the
hook
to make sure that the input stream is fully read or should the servlet
engine. It seems like it would be pretty easy for the servlet engine to
check and I would be willing to take a crack at fixing this (somewhat
obscure) bug. Or am I way off base here?
On another note, it looks like the Jan 18th build doesn't include
xml.jar in
the lib directory so server.xml cannot be parsed. And the Jan 19th / Jan
20th builds seem to have failed for some reason.
Thanks,
Barnaby
--
Jason Hunter
[EMAIL PROTECTED]
Book: http://www.servlets.com/book
2.0 to 2.1: http://www.javaworld.com/jw-12-1998/jw-12-servletapi.html
2.1 to 2.2: http://www.javaworld.com/jw-10-1999/jw-10-servletapi.html
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
