O'Reilly logo

Embedding Perl in HTML with Mason by Ken Williams, Dave Rolsky

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Chapter 9. Mason and CGI

Although mod_perl is pretty cool, it’s not the only way to use Mason to build a web site. In fact, plenty of times it’s more advisable to use CGI than mod_perl, as we describe in this chapter. If you find yourself in such a situation, you’re in luck — Mason works just fine under CGI, and special care has gone into making sure the cooperation is smooth. The HTML::Mason::CGIHandler module provides the glue necessary to use Mason in most common CGI environments.

CGI-Appropriate Situations

Before we get into the details of how to set up Mason under CGI, let’s think about why you might want to use this setup. After all, isn’t mod_perl supposed to be better than CGI? Well, yes and no. As in most things, context is everything. The following factors may conspire to make you choose clunky old CGI over clunky new mod_perl in a particular situation:

Need instant gratification

Installing mod_perl can be somewhat difficult if you’ve never done it before (heck, even if you have done it before), and it can take a while to get used to the peculiarities of developing in a mod_perl environment. If you want to try Mason out but don’t want to spend time installing and configuring mod_perl (or you don’t want to wait for the person who’s going to come install it for you), you may be interested in using HTML::Mason::CGIHandler to start development, then switching over to mod_perl and HTML::Mason::ApacheHandler once you’ve gotten comfortable with mod_perl.

Must share hosting environments

Many organizations simply don’t have the money to pay for their own server and staff to administer it, so they sign up with a cheap virtual hosting service that lets them run CGI scripts. The key word “virtual” means that several organizations, inevitably of varying scruples, share the same web server on the same machine. Although some of these services say they offer mod_perl, you should not use it, because it is very insecure and very prone to catastrophic development errors.

It is insecure because all your code will run in the web server process, along with any other hooligan’s code on your shared server. Unless you trust all those hooligans not to steal your passwords, harass your clients, delete your files, and plunder your village, you should avoid using mod_perl offered in a virtual hosting environment.

It is prone to development errors for the same reason: your code runs in the web server process, so if your Mason code accidentally gets into an infinite loop or hangs the server process, you bring the server down with you. Hosting services tend to dislike that. If you had enough money, you’d handle this problem by running separate servers for development and production, but you clearly don’t have enough money for that, since you’re using cheap virtual hosting.

Good old CGI, unpleasant as it is in other ways, provides a solution. Apache’s ExecCGI mechanism (and its equivalent in other servers) can be configured to use a “setuid” execution mechanism to make sure that your CGI scripts run as the user that owns them — you. This means that you can make all your sensitive data files accessible only by you, that any files your scripts create are owned by you, and that if you make a big mistake, you don’t anger the other people who share your server.

Of course, this argument is moot if your web hosting service doesn’t support the ExecCGI model. Most good full-featured services do, and most crappy ones don’t. Make sure you do the proper research.

Speed not critical

Alas, all the claims of the mod_perl crowd are true — CGI is slower than mod_perl, and it doesn’t provide nearly as much control over the server process. However, sometimes you don’t care. If request speed doesn’t mean too much on your site, and you don’t need to do anything fancy with mod_perl’s various request phases and content management, then there are few, if any, reasons to use mod_perl. mod_perl itself isn’t (necessarily) all that complicated, but the environment you deploy it in can be.

A strong factor in your decision should be rigorous benchmarking; if your site running under CGI can keep up with the amount of traffic you’ll need to handle, then HTML::Mason::CGIHandler holds promise for you. As always, do the proper research.

Special memory usage situations

One of the particular constraints of mod_perl is that it can use a lot of memory. This is mainly due to the persistent nature of the embedded Perl interpreter; memory you allocate during one request may not get freed until many more requests are served and the child process is terminated. Even if you explicitly free the memory when you’re done with it, using Perl’s undef( ) function, most operating systems won’t actually return the memory block to the general pool of free system memory; they’ll just mark it as reusable within that same process. Because of this, mod_perl developers are often quite miserly with memory and will sometimes do convoluted things just to keep memory usage at a minimum.

The persistence of memory creates a problem when you need to have a large chunk of data resident in memory for processing. One of the most common instances of this is HTTP file uploads: if the user uploads a large file, that file will often end up in memory, creating a real problem in a mod_perl environment. However, if the user is uploading a large file, he’ll typically have to wait around for the file to transfer over the network, which means that he won’t really care (or notice) if the receiving script takes an extra half-second to execute. CGI can be useful in this situation, because any memory used during the request will be freed up immediately when the request is over.

Web server isn’t Apache

Although Apache is a great and flexible web server with a huge support team and developer community, it’s not the only web server on the planet. If you find yourself needing to use a server other than Apache, of course you won’t be able to use mod_perl either. Since most web servers support a CGI mechanism of some sort, CGI may be the best way to use Mason in an environment like this.

In fact, even when your web server is Apache, you may want to use a different execution model like FastCGI. Mason’s CGI support extends well into situations like these.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required