While HTTP::Daemon may be easy to use, it is not advisable practice. For one, if you need to write a script to run on YourAverageHost.Com, it will invariably be a CGI script. Even when that is untrue and the script in question is going to run on your own machine, running a HTTP daemon for every single script you may or may not need at one time or other is simply an unnecessary waste of resources (memory, CPU, socket handles) and presents a box with a million open ports to anyone who happens to scan you. And without meaning to be condescending to her, if danielle is asking such a question I doubt she has the experience to have a grasp of all of the security concerns that play a role in writing a daemon (although admittedly CGI is only marginally friendlier an environment).

Makeshifts last the longest.

Ooops, sorry, I'm going to swat you on that one. While you might be suprised at the number of HTTP::Daemons you can start before your system slows, there is no problem with open ports. Perl is incredibly secure, and fooling the perl interpreter remotely to do something bad is unheard of.

danielle would not be writing a daemon, because HTTP::Daemon is the daemon. And HTTP::Daemon is pretty good. The only way you can stuff it up is to send a huge POST request, and then the OS will just swat the daemon for taking up too much room.

I will totally agree with you that HTTP::Daemon is not the right tool for the job most of the time, though.

____________________
Jeremy
I didn't believe in evil until I dated it.

Fooling perl is hard, fooling a Perl script is not so. You do agree that CGI scripts can expose vulnerabilities to a cracker, right? Obviously it is so, otherwise we would not have a lot of tutorials, meditations, nodes, newsgroup posts and who knows what other form of posting in all the different media Perl is discussed via, dealing with how to secure one's CGI scripts.

I also don't follow the reasoning that HTTP::Daemon is the daemon, but the script is not. Granted the specifics of the HTTP protocol are not handled in the script, but use HTTP::Daemon; loads the code inside the same interpreter and process the script runs in. The script does quite certainly provide daemon's actual, functional innards.

Makeshifts last the longest.

there is no problem with open ports. Perl is incredibly secure

(Donning sysadmin hat...)

Regardless of whether that's true or not, it doesn't matter. If you set up your HTTP::Daemon on port 1433, it may not be vulnerable to the MS SQL Server worm that keeps banging on my door, but it'll be more of a drain on the server's resources for the HTTP::Daemon to wake up, determine that the incoming request is gibberish, and reject it than it would for the kernel to just ignore it because there isn't anything listening. Not to mention that simply having the port open might be enough to draw additional attention from people interested in whatever normally runs there. (Same argument applies to any other port, of course, I just picked 1433 because that's where most probes have been directed lately.)