Do you already have some kind of sessioning set up?
If you have:
- Write the PID ($$) of the script processing the upload to the session
- Point your Cancel-button to another CGI script which reads the PID of the upload-script from the session and kill's it
kill 15,$Upload_PID; # Hard-kill and risk half-uploaded temp-files on
+disk, if you write them
kill 10,$Upload_PID; # Send SIGUSR1 to the upload-script
- When using SIGUSR1 (second line above), you could clean up before aborting the upload script, for example:
$SIG{USR1} = sub { unlink $Temp_File; exit; };
If you don't have any sessioning, add a hidden field with some unique token to the upload form. A lovely thing could be: my $Token = unpack('H*',pack('L',time).pack('S',$$));
Your upload script makes itself findable using the token it received from the form (a good idea would be adding the token as GET parameter for early parsing), for example:$0 .= '('.$Token.')';
oropen my $ID_File,'>/dev/shm/tokenfiles/'.$Token;
print $ID_File $$;
close $ID_File;
(You should verify the incoming token for matching /^\da-f$/ for security reasons for both solutions! Don't forget to clean up the file after the upload has finished when using a ID-file.)
Feed the same token from the form to your cancel-script and let it find the PID of the upload process by searching the process table or looking at /dev/shm/tokenfiles/$Token. The rest is the same as above: Now as you know the PID, you could send a cancel signal to the process. | [reply]
[d/l]
[select] |
Liked the main idea :) Perhaps the uploader can write some meta data of what it's doing to the session (instead of some %SIG trickery) and the killer can use that info to wipe-out any residues. However using a form field to identify something on the disk is not a wise thing and a huge security risk. Always use sessions. If you are not sure how to implement one, use one from the CPAN.
| [reply] |
I don't have any sort of sessioning set up, and I am running a WAMP server, so obtaining and killing process IDs isn't viable.
| [reply] |
I switched my server over to lighttpd running on cygwin and implemented your suggestion now that I have access to PIDs. I am just trying to get proof of concept at the moment, and I am running into a little problem. I fork my upload cgi script to create a text file with the PID of the upload script in a separate process.
The cancel cgi script is reading the PID just fine, but the problem is that even though I am forking the upload process, that text file isn't showing up/being created for awhile after the "upload" button is pressed. I am waiting in the parent upload process and put a sleep on the child process(write text file with PID), but it still takes awhile for that text file to show up. Obviously if you click the Cancel button within a second or two of starting, it throws an error, because that file isnt there yet.
Is this a problem that could be helped by using FastCGI?
| [reply] |
That last reply was me. I think this problem may be caused by the way lighttpd operates. It buffers everything before it sends(http://article.gmane.org/gmane.comp.web.lighttpd/3287), so I think the wait period I am experiencing before the file is created is the buffering.
| [reply] |
IIRC this is only possible for Perl running under modperl. perrin will correct me if that's wrong. :) I Googled around a bit on this theme but didn't find what I remember reading 5 years ago.
I doubt that is what you want though. For the general case, if it's really important to clear the file, I'd probably just add a method to your CGI which sends a follow-up "DELETE/POST" when you click "cancel" to remove the file that was just uploaded with the specified identifier/timestamp.
| [reply] |