You could try an applet, though you'll need to sign it with an appropriate certificate. Then the user will be presented with a dialog asking them if they trust the applet: if not, they won't be able to download the file. If so, the download can progress (you'll probably want to put a progress bar in your applet). Note that this isn't perfect - there are problems on some platforms such as Vista:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6548078 The disadvantage with the applet is: (1) you've got to have all clients supporting your applet + JRE version (this is a real bind); (2) the server still can't determine when the transfer's complete except if your applet signals it somehow (i.e. issues another 'special' HTTP request) after transfer.
Second thought: do you really need to cache it locally at all? Couldn't you configure a proxy so when the client makes an HTTP request to your server, it sends a request to the remote server for the file, and all data returned is buffered to the client? That way you never actually store the file yourself at all. You can implement different security mechanisms at each stage with the proxy if necessary. You can probably find suitable software available (e.g. Apache's modules), or build your own with the Java 6 HTTP server (see below).
Finally, if you really must cache, you
could build a second Java application on the server which implements HTTP directly over TCP, and track the underlying connection that way - once the TCP connection (socket) closes or all the data was written, delete the file. This also means your program can monitor the file's last modified date (when it was downloaded to your server), and if it's too far in the past, delete it anyway (assuming the client isn't going to download it - and if they are, they can just go back through the Web page again).
For this last solution, take a look at the new Java 6 HTTP server in packages "com.sun.net.httpserver":
http://java.sun.com/javase/6/docs/jre/api/net/httpserver/spec/index.html You'll also need to be familiar with java.net to get it working, but by all accounts it shouldn't be too difficult. Your only problem then is clients with firewalls which block non-standard ports, since you'll have to run your program as a daemon on another port.
Does that help?