THanks for your answer... I will keep all you said in mind. You are certainly right.
-----Original Message----- From: Wade Chandler [mailto:[EMAIL PROTECTED] Sent: lunes, 05 de junio de 2006 17:08 To: Tomcat Users List Subject: Re: A way to know if file download has ended --- Darryl Miles <[EMAIL PROTECTED]> 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/%3c444FA1E [EMAIL PROTECTED] > > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
