Embedding Perl in HTML with Mason Chapter 9: Mason and CGI

Tham khảo tài liệu embedding perl in html with mason chapter 9: mason and cgi, công nghệ thông tin, kỹ thuật lập trình phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả
Nội dung trích xuất từ tài liệu:
Embedding Perl in HTML with Mason Chapter 9: Mason and CGI Chapter 9: Mason and CGIAlthough mod_perl is pretty cool, its not the only way to use Mason tobuild a web site. In fact, plenty of times its more advisable to use CGI thanmod_perl, as we describe in this chapter. If you find yourself in such asituation, youre in luck -- Mason works just fine under CGI, and specialcare has gone into making sure the cooperation is smooth. TheHTML::Mason::CGIHandler module provides the glue necessary touse Mason in most common CGI environments.CGI-Appropriate SituationsBefore we get into the details of how to set up Mason under CGI, lets thinkabout why you might want to use this setup. After all, isnt mod_perlsupposed to be better than CGI? Well, yes and no. As in most things, contextis everything. The following factors may conspire to make you chooseclunky old CGI over clunky new mod_perl in a particular situation: • Need instant gratification Installing mod_perl can be somewhat difficult if youve 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 dont want to spend time installing and configuring mod_perl (or you dont want to wait for the person whos 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 youve gotten comfortable with mod_perl.• Must share hosting environments Many organizations simply dont 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 hooligans 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, youd handle this problem by running separate servers for development and production, but you clearly dont have enough money for that, since youre using cheap virtual hosting. Good old CGI, unpleasant as it is in other ways, provides a solution. Apaches 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 dont anger the other people who share your server. Of course, this argument is moot if your web hosting service doesnt support the ExecCGI model. Most good full-featured services do, and most crappy ones dont. 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 doesnt provide nearly as much control over the server process. However, sometimes you dont care. If request speed doesnt mean too much on your site, and you dont need to do anything fancy with mod_perls various request phases and content management, then there are few, if any, reasons to use mod_perl. mod_perl itself isnt (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 youll 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 ...