Beefy Boxes and Bandwidth Generously Provided by pair Networks RobOMonk
Problems? Is your data what you think it is?
 
PerlMonks  

Re^4: Why they choose to lie about PHP over Perl

by gellyfish (Monsignor)
on Aug 01, 2006 at 16:14 UTC ( #565034=note: print w/ replies, xml ) Need Help??


in reply to Re^3: Why they choose to lie about PHP over Perl
in thread Why they choose to lie about PHP over Perl

mod_perl is too dangerous for web hosts to offer because it allows you to shutdown, restart and reconfigure Apache from within a Perl script.

This almost identical phrase seems to crop all over the place, with no attribution or supporting evidence as if it is absolutely the case with no possibility of mitigation. It would sound less like some third party cargo-FUD if some example or documentation were provided to be honest. Personally I'm pretty certain that whilst it might be possible to "shutdown, restart and reconfigure Apache from within a Perl script", it is equally not possible to do these things within any Perl script whether the administrator wants this to happen or not.

/J\


Comment on Re^4: Why they choose to lie about PHP over Perl
Re^5: Why they choose to lie about PHP over Perl
by Lies of Society (Initiate) on Aug 01, 2006 at 16:47 UTC

    mod_perl embeds a Perl interpreter in Apache. You can do all sorts of crazy shit to Apache using mod_perl. Here, read this to see what kind of hoops an ISP has to jump through to support mod_perl, and ask yourself why anyone would bother with that when there's an alternative like PHP. I'm not saying PHP is a better language (it isn't) just that mod_php is better and that mod_perl isn't an option for most of the people that use PHP.

      Yes I know mod_perl embeds a Perl interpreter in Apache. In much the same way that mod_php does with a PHP interpreter.

      However, doing "all sorts of crazy shit to Apache using mod_perl" isn't the same as having the ability to "shutdown, restart and reconfigure Apache from within a Perl script", infact the article you cite doesn't give any of those things as a risk of providing mod_perl in a shared hosting environment.

      /J\

        I don't think it's the same. mod_perl really is the same perl process just running different functions for each page. The typical configuration for PHP offers more isolation than mod_perl does under any configuration I'm aware of. We'd have to prevent one mod_perl page from being able to see other mod_perl pages by proxy of the symbol table or other interpreter globals. To do that, we really do need separate processes. I think we solve this by using FastCGI, the same thing that I hear Rails typically runs on.

        ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (6)
As of 2014-04-19 02:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (475 votes), past polls