LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (https://www.linuxquestions.org/questions/programming-9/)
-   -   [webserver]cgi/perl or php (https://www.linuxquestions.org/questions/programming-9/%5Bwebserver%5Dcgi-perl-or-php-703829/)

Wim Sturkenboom 02-11-2009 04:55 AM

[webserver]cgi/perl or php
 
Not sure if this belongs here or in linux-server.

I'm currently doing a code audit on a web application which serves a number of pages from cgi-bin using perl scripts.

Someone asked me if it was maybe better to convert them to php and create 'normal' php pages (not using cgi-bin) or even asp.

I can not answer the question as I have never used cgi-bin or perl.

So the question is if there's much of a difference in the approach and what are the advantages/disadvantages of both methods?

I will draw my own conclusions.

rylan76 02-11-2009 05:37 AM

Hi

Lekker om nog 'n Suid Afrikaner hier te kry.

IMO it is only a matter of "taste" if you will. Using CGI will allow you to code whatever you want to do in C / C++ or another compiled / non-PHP language, and then have the application run as a normal process on your machine, triggered via CGI. If however, the task that you want to do does not require some kind of "non-php" (again, depends on your point of view) behaviour / service / activity, it might make more sense to simply use the PHP FastCGI executable to do whatever you want, thus having some cohesion across your setup.

For example, poweralert.co.za uses "deferred" PHP (executed by Apache OR via the CGI PHP executable) to build the site pages and update them every 10 minutes.

AFAIK using CGI to call a binary application is mostly useful if you have a precompiled binary that does something useful you want to tie to a webpage / site. If however, you want a high degree of consistency across your code, just do everything with PHP since PHP can run as an Apache module as well as a CGI-callable / cronnable script.

Su-Shee 02-11-2009 02:48 PM

It's just a matter of preference.

Perl can be used embedded into HTML "the PHP way" the same way as PHP can be installed to work as CGI only.

Perl's got the "-T" switch, which I consider a huge advantage when it comes to programming.

-T essentially enforces to check ALL incoming and outgoing "stuff" from the viewpoint of the Perl script for security issues.

Don't know wether or not PHP's got something similar.

theNbomr 02-11-2009 04:27 PM

It can be seen as either a blessing or a curse, depending on your situation, but PHP can be used from $HOME/public_html directories, whereas Perl used as a CGI cannot. I'm no expert on Apache or other web server configuration, so I suppose it may be possible to override these conditions, but they have always been the standard configuration on any web server I've set up.
Perl can easily be made to enforce programming rules using 'use strict;' and the '-w' switch. These can save no end of aggravation and debugging time. I don't think PHP has such a feature.

--- rod.

Su-Shee 02-12-2009 05:08 AM

Of course Apache can be (easily) configured to serve Perl CGIs from a user's web dir - if a webhoster offers Perl, they usally serve traditional Perl CGIs just fine.

But this is no issue of the programming language itself but of the style and configuration of the webhoster/webserver.

j-ray 02-12-2009 06:49 AM

PHP will scale a bit better in heavy duty than perl/cgi and in perl you can integrate more complex functionality more easily.
If you want to create an object oriented application you will be better off using mod_perl. Here all classes can be loaded by the server at server start. But it requires some more reading. So if you expect a lot of visitors this would be a good alternative.

You can use both languages in a web application simultaneously, though. You can even share sessions among the both parts with perl module PHP::Session.

chrism01 02-12-2009 06:20 PM

Actually mod_perl loads the perl into apache, so minimizing the startup overhead, and caching any perl scripts already run once.
mod_php does the same for PHP.

Result is a much faster site for busy sites. There are some gotchas, but the main one is that it actually caches the script state, so not just the code, but the last variable values set. So, always init all variables to a known value at first use/declaration, otherwise old values may be used.

Wim Sturkenboom 02-12-2009 09:40 PM

Thanks people for the info.

The application failed the audit because of the possibility to bypass login and the fact that it does not check for POST or GET. So I can pass all my parameters in the URL and it will happily do what I tell it to do and not what the refering page wanted it to do.

j-ray 02-13-2009 02:57 AM

@chrism01
you can configure mod_perl to cache all scripts or not using different handlers Registry vs. PerlRun and others. If you use PerlRun the srcipts are parsed with every request as in PHP. It is still much faster than CGI but you can use usual CGI programs without completely rewriting them as it would be necessary with the Registry handler.

Su-Shee 02-13-2009 11:21 AM

Quote:

Originally Posted by Wim Sturkenboom (Post 3441786)
Thanks people for the info.

The application failed the audit because of the possibility to bypass login and the fact that it does not check for POST or GET. So I can pass all my parameters in the URL and it will happily do what I tell it to do and not what the refering page wanted it to do.

And _that's_ just bad programming.

Just sad, that people still don't read one of the 98604860 tutorials about web programming...

And so easily avoided in Perl...


All times are GMT -5. The time now is 11:21 AM.