Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Combining PHP and Perl

by rodry (Beadle)
on Oct 07, 2000 at 03:03 UTC ( #35687=perlmeditation: print w/replies, xml ) Need Help??

I recently started using PHP on my personal server, and I must say that I like what I have seen so far. A language with a familiar syntax, faster than CGI Perl, and that allows for persistent DB connections without having to add extra modules to your server (this is very important for those of us who rely on hosting services and virtual accounts).

Having spent so much time and resources on Perl, I am beggining to wonder if I chose the right path in using it to develop web based solutions. I want to ask the monks in what ways can a developer combine this two technologies, so as to take advantage of the fact that a developer is familiar with both.

Thanks.

Replies are listed 'Best First'.
(Ovid - PHP danger) RE: Combining PHP and Perl
by Ovid (Cardinal) on Oct 07, 2000 at 03:43 UTC
    If you like PHP, use it at your own risk. Check out the following security alert. Here's a bit of text from the alert:
    The way that PHP handles file uploads makes it simple to trick PHP applications into working on arbitrary files local to the server rather than files uploaded by the user. This will generally lead to a remote attacker being able to read any file on the server that can be read by the user the web server is running as, typically 'nobody'.
    According to the alert, they don't know of any way to really fix this problem, short of a new version of PHP being rolled out.

    Cheers,
    Ovid

    Update: First, thanks for pointing out how to protect against this vulnerability. I'm not trying to say that PHP is evil, just that there is a known issue with it (and I'm not claiming that there aren't issues with Perl).

    Next, I can see people voting me down for making a rude post, but why vote me down for letting people know about security issues? I would presume that people would prefer to know about these things. If there is a fix, people won't bother to apply it if they don't know what about the original vulnerability is.

    I will confess that I didn't follow the links, but in seeing them, I see bad security advice in one: check to verify that the file sizes are the same and reject them if they aren't. Fine, so all I need to do is keep sending files in increments of one byte until I get a hit. That's pretty simple to crack.

    The other one -- verifying the filename -- is obvious and I wouldn't have realized it since I don't know PHP. However, I still let my original post stand. There is a security issue and "according to the alert", the author didn't know how to fix it. I still feel it's important to raise issues like this because people should be aware of them.

    Join the Perlmonks Setiathome Group or just go the the link and check out our stats.

      Darn, I hate playing PHP apologist all the time. That securityfocus page has been up for some time, and there is an easy fix *in PHP* for it. It's called "checking the filename before you use it." Sure, it's a bit of a pain but it will have a more permanent fix soon. The PHP manual says this (now). If you follow the thread on securityfocus that Ovid posted, you can see how the PHP team responded.

      Back to the question at hand: PHP lacks a few features that I find handy in Perl, but of course the lack will only bother you if you use these features. I am otherwise a staunch advocate of the "use what works," so if you find that PHP works for you, use it. Just don't come cryin' here when it doesn't work for you =)

      • no 'use strict;' equivalent in PHP -- this would help with debugging, at the very least.
      • no complex data structures in PHP, AFAIK
      • PHP can use Perl-compatible regexes, but I find the implementation counterintuitive.
      • while it has great DB support, PHP lacks 'placeholders' for database inserts; this makes security here a little more painful, and also potentially slower.

      But PHP is still young, so this may all change.

      Philosophy can be made out of anything -- or less

      Just a comment.... your initial posting (pre-update) started with a generally negative statement, *then* qualified that, by going into detail.

      "Use it at your own risk" is true of any language/system/whatever.... including php and perl, but in this instance, I think overstates the problem.

RE: Combining PHP and Perl
by pope (Friar) on Oct 09, 2000 at 12:55 UTC
    php is hard to compare with Perl itself, for Perl is a general purpose language. It makes much more sense to compare it with several server-side scriptings based on Perl, such as Embperl and HTML::Mason.
    Embperl is page oriented, fast (written in C/XS), and added syntatic sugars for web development convenience. HTML::Mason is written in pure perl, more site oriented, and offers many features which is hard to find on other templating systems such as dhandler, autohandler, caching, and output filtering. Assuming that these are run under mod_perl, Mason is slower than Embperl, and I think Embperl performance is comparable to php's. Raw mod_perl is faster than php. But I don't think that this speed differences is significant in most web apps.

    An apache + mod_perl httpd size is large, 10-20M is typical after loading some required perl modules. So you may take this into account when you want to build an apache + mod_perl + mod_php + mod_? php is appropriate for most web tasks, but if you want some esoteric functionality, or you want to get the best performance, you'd better use mod_perl.

RE: Combining PHP and Perl
by Anonymous Monk on Oct 08, 2000 at 13:59 UTC
    PHP is great. For some things it's undoubtedly the right toold for the job. Perl has a much wider scope of application, because it is a programming language, plain and simple, not a web programming language. You mention that at the moment your solutions are based on shared-server type environments, in which case it is indeed very hard to make use of many of Perl's features. However, if and when you get beyond that, and start to develop solutions where you are, and need to be, in full control of the server, your Perl experience will be invaluable. Firstly, for a host of tasks NOT related to the actual generation of web pages - server management, batch processing, data cleaning, data import and export, and thousands of other things. Secondly, it will become apparent that while PHP may be great for 90% of your requirements there will be times when it will be better to write something in Perl. Suppose you want to interface to Cybercash? Suppose the site needs to automatically send a PGP signed email at some point? Maybe you want to generate images automatically somewhere? There may be PHP libraries available to do all these, I don't know, but Perl can certainly do all this with ease, and there will always be cases where Perl makes it easy.
      Cybercash = Ugh!!
      Live Processor = Ahh...Relief!
RE: Combining PHP and Perl
by pandr (Acolyte) on Oct 15, 2000 at 12:44 UTC
    A lot of wise advise has been given already. There is one additional point you may want to consider. It is somewhat related to Tom's "GUIs Considered Harmful". The whole post can be found at guis but I will quote a small part here:

    "It's all well and good to place a GUI wrapper around an existing tool, but to design a new application with only a GUI interface in mind is to forever limit that tool's flexibility."

    Because web programming is similar to gui programming you have the very same pitfalls. Consider a portal like site where users are allowed to create accounts. You may start by implementing this in pure PHP (the create_account.phtml page) and this typically involves DB access, password checking and what not. As your site grows you want to be able to administrate it in a more effecient manner, so you write a command line tool (in Perl) to allow quick (i.e. scriptable) handling of the accounts. This is were the pain begins. Now you have identical logic (SQL-statements, password checks, etc.) implemented in PHP and in Perl. Of course you know that is bad, but if you have thousands of lines of PHP code you are trapped!

    I am not saying PHP is bad. I use it myself from time to time. But I have seen people get burnt by the above scenario.

    (Yes, I know PHP can be used to create command line scripts, but that is definitely NOT where its strenghts are, IMO)
      Now you have identical logic...implemented in PHP and in Perl.

      I have noticed this myself, even in the admittedly simple uses I've put these two. One my sites is based around templates originally generated by PHP3. Given PHP's security problem with multi-part forms, I decided to implement an upload process using perl.

      In doing so, I found that I had to re-design my template process to make them easier to share between PHP and perl. While a reasonably trivial task, it did take some time that I could have used for other portions of the project.

      The lesson, then, is to take some extra time during your design phase to make sure that your implementation can suport multiple tools and processes.

RE: Combining PHP and Perl
by AgentM (Curate) on Oct 07, 2000 at 05:38 UTC
    PHP is not a fully-featured language like Perl so you might miss out on something you find standard in Perl. Also, considering speed, Perl will often beat PHP in comparable matches which usually will involve mod_perl or fastcgi since a generic CGI is not a fair comparison. Plus, with Perl you get great support, FOR FREE! Don't believe me? Check out PHPmonks.org. Aw! Dead link? Sorry. Perl has far more many general purpose and useful modules available all in one place. For example, try to find the useful, well-reviewed Bone::Easy module for PHP. It ain't gonna happen, folks. Anyway, I see CGI as a wrapper for HTML not vice versa as in PHP.
    AgentM Systems or Nasca Enterprises is not responsible for the comments made by AgentM- anywhere.

      I was trying to type in "http://www.phpmonks.org" and accidentally typed in "http://www.phpbuilder.com", but that didn't work. Trying again, I typed in "http://www.zend.com". Stupid PHP, you can't even spell the name of its support websites right.

        Maybe a bit counter intuitive,
        but you might try php.net...;)
      I think one of the reasons that there isn't the same amount of support for PHP as there is for Perl is that it's only relatively recently become popular. The newsgroup alt.php has only just started up and seems to be getting busier by the day; lots of newsservers didn't carry it at first. The online documnetation is excellent, something which I personally think is a lot more useful than Perl's docs, and there are quite a few websites out there that are useful forums for learning about and discussing PHP.

      I think that PHP has it's uses and can be used in conjunction with Perl to get stuff done. They both have their advantages and disadvantages, but you can only really make up your own mind on the matter by trying them out. Try doing the same task in PHP and then try again in Perl - sometimes PHP will be best for the job and sometimes Perl will.

RE: Combining PHP and Perl
by footpad (Abbot) on Oct 13, 2000 at 00:09 UTC

    rodry,

    In my opinion, having skills in both can only be a good thing. Each was designed for different purposes; each can solve some of the same problems. However, the more tools you have in your kit, the more likely you'll be able to choose the correct one for the specific problems you encounter.

    Besides, it can only make you more marketable in the long run.

    -- f
RE: Combining PHP and Perl
by swiftone (Curate) on Oct 13, 2000 at 00:24 UTC
    Well, this isn't so much of a PHP v Perl issue as a general web issue, but this is the first forum that it's relevant to at all since I thought of it, so I'll post it here.

    I've recently been learning mod_perl, and working at moving my mindset over to it. It's not difficult, so much as a drastic mental switch. I've always avoided PHP, ASP, Coldfusion, Embperl, and other solutions of those types. I recently discovered Text::Template, and I love it. What's the difference? Dependence on the webserver.

    With CGI Perl and Text::Template, I have command line scripts that are optimized to work with HTML browsers, but that function and are accessable without them.

    When you convert to mod_perl, your documents cease to be apps, and the webserver stops being a document server, and instead becomes (in the words of merlyn), a programmable app.

    Since I tend to prefer to keep things low level and accessable (ASCII forever!), this is a bit of a drastic switch. So when looking at PHP and Perl, think about how you want to view your documents.

      swiftone said:

      With CGI Perl and Text::Template, I have command line scripts that are optimized to work with HTML browsers, but that function and are accessable without them.

      Can you provide us with some samples of documents you have that work (seamlessly?) for both web service and command-line use?

      On this topic, Tom Christiansen floated a paper across Usenet awhile back that you should try to get if possible, named "GUIs Considered Harmful". In it, he states that an application should be useable from programs, the command line and the GUI.

        Can you provide us with some samples of documents you have that work (seamlessly?) for both web service and command-line use?

        I never claimed seamlessly :) What I meant was that any CGI script using CGI.pm should be able to be run from the commandline. For large sites, I currently use Text::Template to import/interpret templates (much like HTML::Template, etc), but I write the resulting HTML to flat files that the webserver serves. (even mod_perl has problems hitting the speed of flat HTML). With flat files holding content, I can manipulate the pages with scripts and other *nix tools such as grep, ispell, etc.

        Of course, this prevents me from having truly user-specific dynamic pages, so I write any of those with CGI perl scripts. When those scripts become large portions of the site, mod_perl is clearly a better solution. But it's a different mindset.

        Tom Christiansen floated a paper across Usenet awhile back that you should try to get if possible, named "GUIs Considered Harmful".

        I'll look for it, thanks

compiling apache with mod_perl (DSO) and php4
by meonkeys (Chaplain) on Nov 04, 2000 at 02:48 UTC
    The following applies to Unix:

    If you are crazy and DO decide to compile Apache with php4 (with mysql support) and mod_perl (as a DSO), make damn sure you use your own mysql library and header files. If you installed mysql from binary or source rpms, the required files are in /usr/include/mysql and /usr/lib/mysql, so you tell php:
    ./configure --with-mysql='/usr'

    and it's able to find everything it needs. If you use the mysql headers/libs included with the php source, you may witness unexplainable segfaults when trying to use modperl DBI connects to a mysql server. Here's my build script in case you're interested...
    #!/bin/sh # # build_apache.sh # # -------install Apache using DSOs-------- # # first, untar apache, mod_perl, and php in a common dir. # my tree looks like this: # /tmp/apache # | # ./apache_1.3.14/ # ./apache_1.3.14.tar.gz # ./build_apache.sh # ./mod_perl-1.24/ # ./mod_perl-1.24.tar.gz # ./php-4.0.3pl1/ # ./php-4.0.3pl1.tar.gz ########################################################### # prebuild apache for php cd apache_1.3.14 rm -rf config.cache make clean ./configure --prefix='/usr/local/apache' cd .. ########################################################### # build php cd php-4.0.3pl1 rm -rf config.cache make clean ./configure --with-mysql='/usr' --enable-track-vars \ --with-apache='../apache_1.3.14' # mysql header files in /usr/include/mysql # mysql library files in /usr/lib/mysql # (this is the default from an rpm install of mysql) make make install cd .. ########################################################### # build mod_perl cd mod_perl-1.24_01 rm -rf config.cache make clean perl Makefile.PL \ APACHE_PREFIX='/usr/local/apache' \ APACHE_SRC='../apache_1.3.14' \ NO_HTTPD=1 \ USE_APACI=1 \ PREP_HTTPD=1 \ EVERYTHING=1 make make install cd .. ########################################################### # build apache cd apache_1.3.14 rm -rf config.cache make clean ./configure --prefix='/usr/local/apache' \ --enable-module=rewrite \ --enable-module=proxy \ --activate-module='src/modules/perl/libperl.a' \ --activate-module='src/modules/php4/libphp4.a' \ --enable-shared=perl make make install cd .. ########################################################### # fin

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://35687]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (7)
As of 2020-11-27 14:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?