It sounds like you've done the hard part already - good job!

I suggest the following: if your auto refreshing dummy page is using a meta tag with refresh - get rid of that. Think of your dummy page as a "status" page instead. Add some javascript to the page that will generate status messages via AJAX requests.

One quick and easy way to do that is to modify your child process (the one doing all the work) so that it writes out status messages to a special log file (needs to be readable by the user your web server runs as). Then create a cgi script that reads in this file dumps it to stout. If you point your web browser to this cgi script, you should see your status messages as plain text. Your 'status' page needs to have an empty DIV with a unique ID. Your ajax code will basically ping your cgi script every few seconds, and stuff whatever output it gets into that DIV element. Start the first ajax request in an onload() event, then make sure the last thing the request handler does is schedule another request in 10 seconds (or however often you think makes sense).

Note that you can replace all your 'die' statements with something custom, like 'mydie'. These will write the error message to the special status log file before dying - that way the event will show up on your status page.

You can also store the child processes PID in a file when it first launches, then have the status cgi script check to make sure it's still running. If it disappears from the process list before finishing the job, you'll know something has gone horribly wrong.

Once you get the basic idea working, you can get fancy: you can use JSON to stringify an entire perl data structure and pass it to your status page via ajax. You could use this to create a kind of "control panel" app, able to manage multiple jobs at once, and implement features like "start job", "stop job", "kill job", etc.