in reply to Re^3: How to Fix CGI
in thread How to Fix CGI

ISP and shared webhosts cannot provide mod_perl simply because: with mod_perl, users can do deadly things by specifying Perl* directives in their own .htaccess files. There is currently no way to forbid this. There is in mod_ruby. Patch for this has been submitted (maybe more than once), but rejected. I don't think mod_perl developers care enough about shared hosting environments.

Replies are listed 'Best First'.
Re^5: How to Fix CGI
by perrin (Chancellor) on Nov 29, 2007 at 15:21 UTC
    That's absurd. First, there is nothing that can be done via .htaccess directives that's any worse than code you can write in mod_ruby or mod_php. Second, there has never been a patch like you describe submitted to the mod_perl dev list. I've been on it for years.
Re^5: How to Fix CGI
by arkturuz (Curate) on Nov 29, 2007 at 16:19 UTC
    So, why not write a mod_perl module that will do just that (restrict user powers)? ISPs could then configure their servers to force using mod_perl powers via this module only. Users gain speed, performance, DB persistance, etc; ISPs gain control.

    I'm still learning mod_perl, but from what I read, I think something like this is very possible. Most of the users don't need the full mod_perl horse power, just a small, but still significant, subset. Module like this could enable it, I believe, exporting some API and handlers users should then use instead of default ones, and controling that default stuff doesn't get called.