tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Problems downloading files. How to identify the CANCEL button?
Date Wed, 08 Jul 2009 10:40:05 GMT
Pid wrote:
> On 7/7/09 19:09, wrote:
>> Dear all,
>> I need to log some information only after a user downloads or opens a 
>> file.
>> I am using a servlet for that and the download part works fine.
>> However I need to identify which button was clicked because in case 
>> the user
>> clicks [CANCEL] I am not supposed to register any information.
>> I put lots of messages on the code to understand how it works and even 
>> if I
>> click [CANCEL] the messages will be printed showing that all commands 
>> will
>> be executed no matter which button was clicked.
> There is nothing in either the Servlet Spec or standard accessible 
> browser functionality that will provide something so specific.
> AFAIK the only thing you can look out for is an exception during the 
> phase where you're writing to the output, as interrupting the streaming 
> of data to the output stream may throw a catchable exception.
In addition to the above, consider the following :
Between your Tomcat server, and the user with his browser, there may be 
2 proxy servers and a slow internet connection. Imagine all of that is 
very slow, so that you can see the data blocks flowing.
When your Tomcat app starts sending the file, the data blocks start 
flowing from Tomcat to proxy-A, from proxy-A to proxy-B, and from there 
eventually to the browser.
Now the Tomcat webapp is done sending to proxy-A, and from its point of 
view everything has been sent succesfully and it is done.
But there are still a number of blocks in transit out on the Internet, 
in the memory of the proxy-A, in the memory of proxy-B, etc..
Now the user clicks the cancel button, or moves to another page.
His connection to proxy-B is broken, and proxy-B deletes all the blocks 
it still had to send. Proxy-B also closes its connection to proxy-A, 
which causes proxy-A to delete all the remaining blocks it had to send.
But your Tomcat webapp doesn't know anything of that, because it is long 
done and gone away...

The above may sound like an extreme example, but it isn't.  I work 
regularly with servers which are several "hops" away from my browser. 
Some proxies will cache the whole file locally, before even starting to 
send it to the client browser.

Basically thus, even if you detect all possible network transmission 
errors at the Tomcat level, you still would not know if the user has 
really received the whole file.

The /only/ way, from a design perspective, to make sure, is some 
architecture whereby, at the user browser side, something checks that 
everything has been received, and then sends back some OK signal to your 
webapp, to acknowledge the full data reception.
That could be, for example, a Java applet running at the browser side, 
or maybe some Java code using XMLHttpRequest (usually referred to as 

It also complicates things quite a bit, but hey that's what we 
programmers do for a living..

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message