Ted Neward wrote:
>
> C'mon, guys, read the HTTP specification--there's no way for the browser to
> send a "stop" signal to the server, because HTTP itself is request/response
> oriented. Any new communication from the browser will simply create a new
> request/response pair, rather than cancel the old one.
>
The user agent can close the TCP/IP connection in the middle of
the download. Eventually, the server will recognize this and
close the TCP/IP connection on that end as well. If you're
programming through a high-level interface like Java you're
going through a number of buffers, so the exact point that
the writer gets usefully notified of the client's closed
connection is a little hard to predict. (Also, there might
be proxies in the pipe, at which point things get _really_
hard to predict)
Using JDK 1.1.x, I've found (in a non-servlet based app talking
directly to the server)that doing a flush on the socket stream
every once in a while will trigger the appropriate exception.
However, if I don't do a flush, I've been able to consistently
write very large streams to a connection that's been closed on
the client side. (I did a tcpdump of the process, and sure enough,
the os knows, but Java doesn't)
In any case, it's arguable the responsibility of the servlet
container writer. There's probably not much a servlet
author can do (Although, hmm, maybe calling flush() on the
output stream every once in a while might help. Of course,
that's not guaranteed to do a flush on the actual socket
output stream, but it might be worth a try as an experiment)
Christopher St. John
[EMAIL PROTECTED]
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
