tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: A way to know if file download has ended
Date Mon, 05 Jun 2006 15:07:55 GMT
--- Darryl Miles <darryl-mailinglists@netbauds.net>
wrote:

> Bachler, Elisabeth (Elisabeth) wrote:
> > Thank you to everyone. I will investigate further.
> > Elisabeth
> 
> Maybe this thread is related (excuse the horid
> apache web interface) :
> 
>
http://mail-archives.apache.org/mod_mbox/tomcat-users/200604.mbox/%3c444FA1E2.8010005@airweb.fr%3e
> 
> 
> Darryl
> 
Just remember there are so many other issues.  I say
that not to be pessimistic, but to be realistic to
maybe keep you from spending too much time on it.  For
instance, when you download a file using Firefox,
firefox will be downloading the bytes from the server
even while you are deciding to cancel or save and will
be storing this information into another buffer.  This
is why when you finally hit save if the box has been
up a while you'll notice a jump in the downloaded
bytes then the status of the download speed jumps back
down to the real value.  I mention that because I
don't know how much you are wanting to rely on
"successfully downloaded" which you mentioned in your
first email.  The user might hit cancel even after the
file has technically been successfully downloaded even
if only to temp space they can't retrieve in any easy
manner.  

There is also the issue of HTTP proxies and caching
and read ahead, all of these things affect HTTP and
the ability to be able to tell what actually happened
at the byte level between the client and server. 
Also, even if the user closes the browser ... you can
still write to the servlet API output with no error
being raised.  This is also true in Microsoft ISAPI
dlls.  I don't even think if you got at the low level
where the server is if you could reliably do this
because of the proxies and caches I talked about. 
Your proxies and caches and even the users may not be
the only ones in the pipeline, so you always have to
keep that in mind.  

We had an issue one time where bytes were getting cut
out of an https connection, but not an http
connection, and later we found an ISP in between us
and a client had some software in between that was
dropping bytes out of https when too much information
passed through and we finally figured that out and
they fixed it, but not just the fact that they didn't
pass the information back wouldn't affect you, but
also the fact that the software in between could be
reading more bytes than you request at a time to help
speed up users of the ISPs connections over HTTP and
keep doing this even when the TCP connection is
severed.

Wade

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message