Beefy Boxes and Bandwidth Generously Provided by pair Networks Joe
Keep It Simple, Stupid
 
PerlMonks  

Re: Re: mod_perl and shared environments don't mix - do they?

by zaimoni (Beadle)
on Nov 11, 2002 at 02:17 UTC ( #211840=note: print w/ replies, xml ) Need Help??


in reply to Re: mod_perl and shared environments don't mix - do they?
in thread mod_perl and shared environments don't mix - do they?

PHP is deliberately specialized for web pages. This theoretically makes it easier to develop web interfaces quickly using PHP. It's not meant for general pattern processing.

The PHP interpreter is written directly in C. Perl runs (after compilation) as a bytecode interpreter. I think that this is the other main advantage of PHP: response time should be improved by using one layer of interpretation instead of two. I'm not familar with the internal data representation of PHP, so I can't immediately compare the two languages that way.

Unfortunately, PHP's strength (interpreter written in C) is also its critical downfall, from a network security perspective. I have advised two clients not to use PHP for publicly exposed scripts because of repeated "arbitrary code execution" buffer overflow bug reports in PHP's POST parameter parsing code...I think I've seen at least three distinct reports of this in 2002. So far, both clients have taken my advice.


Comment on Re: Re: mod_perl and shared environments don't mix - do they?
Re^3: mod_perl and shared environments don't mix - do they?
by Aristotle (Chancellor) on Nov 11, 2002 at 02:35 UTC

    I don't quite follow.

    perl is written in C as well. It compiles scripts to bytecode which it then executes.

    The PHP interpreter is written in C, but does not compile PHP scripts to machine code. It still interprets them.

    There's no difference there.

    As far as security is concerned, I actually believe there is a whole lot of reasons to distrust PHP. Among others, POST and GET parameter names used to become global variable names - and a lot of folks I've seen writing PHP code still look at me like an alien when I tell them they switch that behaviour off. (Apparently, writing $HTTP_POST_PARAMETER[] or whatsitcalled for every variable is too much work.) A lot of sins any sane Perl programmer would advise against were freely committed in the PHP world in the name of convenience, and are only slowly being undone.

    PHP is nice, sort of like shell scripts - so long as your task is miniscule, it is quite handy and can get the job done in record time. It isn't anything I'd like to build a complex application with however.

    Makeshifts last the longest.

Re: Re: Re: mod_perl and shared environments don't mix - do they?
by perrin (Chancellor) on Nov 11, 2002 at 02:36 UTC
    I was actually asking why PHP is considered okay to run in shared environments from a security standpoint, not why people like to program it.

    Your facts about PHP and Perl's architectures are not correct. Both of them are written in C, both of them compile to bytecode before execution, and even with a bytecode cache like the Zend cache, Perl is still faster than PHP.

    Perl is equally vulnerable to buffer overflows, being written in C as well. The reason you don't see many reports of these problems in Perl is that a lot of people spent a lot of time finding and fixing them. The core Perl 5 codebase has had many years to mature.

Re: Re: Re: mod_perl and shared environments don't mix - do they?
by diotalevi (Canon) on May 21, 2003 at 14:34 UTC

    The PHP interpreter is written directly in C. Perl runs (after compilation) as a bytecode interpreter. I think that this is the other main advantage of PHP: response time should be improved by using one layer of interpretation instead of two.
    Perl does not use bytecode and there isn't an extra layer of indirection. You'll be better off if you just strike this bit as no part of this is meaningful.

    I'm not familar with the internal data representation of PHP, so I can't immediately compare the two languages that way.
    I'm not familiar with PHP's guts - apparently you aren't familiar with perl's.

    Unfortunately, PHP's strength (interpreter written in C) is also its critical downfall, from a network security perspective. I have advised two clients not to use PHP for publicly exposed scripts because of repeated "arbitrary code execution" buffer overflow bug reports in PHP's POST parameter parsing code...I think I've seen at least three distinct reports of this in 2002. So far, both clients have taken my advice.
    Again, this misses the point. Perl is subject to all the same problems. The difference is that perl is vastly more mature and these sorts of issues have just been shaken out by now. There's also some benefit in that CGI.pm's parameter parsing code is written in perl so you only have an exploitable bug if there's something wrong with perl's string handling. Apache::Request though - that's written in C and again it plays in exactly the same ballpark. The difference is again, relative maturity. All this means is that in a few years PHP will be sitting pretty.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (9)
As of 2014-04-19 05:12 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (478 votes), past polls