Prologue: I'm your target audience. I like CGI.pm quite a bit and have written a couple thousand scripts, production and personal, with it at several jobs including Amazon.com.

I also love the (can't call them new at this point, Catalyst is 13 years old) frameworks and raw Plack/PSGI but I use CGI.pm (::Pretty) now and then for the odd test or to generation a little boilerplate. Has nothing to do with fad or some imagined new:old dichotomy. I do what I want. CGI is monolithic and has some punching power in its weight class because of it but it's inferior to modern practices and tools on most levels, especially as a calling card. I agree that CGI.pm should not be removing features.

That said, your proposal contains some unflattering ironies and inaccuracies and boils down to anonymously insulting and cajoling others into doing what you have the power to do. I agree with your basic premise but still downvoted you for the presentation and "volunteering" others.

CGI.pm isn't core anymore. It's never going back in. Apache's market share is on a strong downward trend. Nginx is the opposite and the only webserver that is. If these trends hold, nginx will be the most popular and widely used server in a few more years. Nginx doesn't even support CGI.

Being out of the core means there is no reason at all not to fork CGI.pm at whatever version you feel is backwards stable and port fixes going forward. I'd help patch and such a project if were on github and run in a community positive, feud free fashion. On that note, I submitted a modernization fix to LEEJO and it was accepted and applied instantly.

Epilogue: Anonymous Monks have no "we." Use your name or say "I."

Apache's market share is on a strong downward trend. Nginx is the opposite and the only webserver that is. If these trends hold, nginx will be the most popular and widely used server in a few more years. Nginx doesn't even support CGI.

Because Nginx is a toy compared to Apache. It fills one little niche very well: replace reverse mod_proxy, on high traffic sites, so the mod_perl application server can get even more action! My brand new Macbook Pro came loaded with Apache/2.4.29, mod_perl/2.0.9 and Perl/v5.18.2 (which still includes CGI.pm yay). Simply edit config, flip the switch, and throw code at it. Nginx is not present, needed, nor welcome for such tasks. Apple has been very good to us. None of my linux distros even include Apache let alone mod_perl.

"...Nginx is a toy compared to Apache... My brand new Macbook Pro came loaded with Apache..."

Sure. And a Macbook is a great platform to run a high-performance web server. And my cellphone is stronger than your fax machine. And my dick is a monster.

Best regards, Karl

P.S.: How many serious projects did you do with nginx - if any?

«The Crux of the Biscuit is the Apostrophe»

perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

I'm an Apple user going back well before OS X; and an apache user since '98. Nginx is so much better than apache as a pure webserver that it is somewhat ridiculous. The idea that you think a toy, deeply popular with open source developers, could be eating the market share of every single other webserver because of fashion or corporate pressure shows that you're either not serious or don't know what you're talking about.

Epilogue: Anonymous Monks have no "we." Use your name or say "I."

I have to we , do your mother?

If I were to single out one Perl module that has changed the world, then this would be CGI.pm. It opened the door to write Perl software for the then-young WWW before the full impact of how WWW would change everything could have been imagined. Maybe it considerably contributed to said impact.

Occasionally I am contributing to an open source project which uses CGI.pm since its beginning (TWiki). About three years ago Lee Johnson informed the dev team about his plans, and as far as I can say, he put considerable effort into informing the public about the upcoming changes. Our project makes use of the features which are no longer available in CPAN's CGI.pm, in particular, the HTML generating stuff. Nobody wanted to spend the effort to eliminate all of that. So we could have forked a CGI::Legacy module which kept all the stuff. But actually I wasn't too happy with the HTML generating stuff because it became obvious that it is rather difficult to extend. So, instead, we decided to package a frozen version of CGI.pm together with TWiki, and eliminate that old stuff in our own time. No shouting required.

I'm used to the fact that old code needs to be changed occasionally. Compared to other languages, Perl shines when it comes to allowing for long lifetime of software with just a few changes. Nonetheless I'm trying to keep up with best practices when writing new code. As of today, I am perfectly fine with the current CGI.pm. And quite often I won't use it at all in favour of PSGI. The concept of passing variables as environment variables was a kludge at best (not Lincoln Stein's fault), and I'm glad we can now work without it.

Now, what about CGI::Alternatives? I appreciate that Lee Johnson has put some effort into showing ways to migrate from CGI.pm. He shows how to replace just the HTML generating stuff with TT, and then how to avoid direct use of CGI.pm altogether.

CGI::Alternatives is a module that "doesn't do anything"1 except vehemently deny and propogandize against the utility of one of the most useful forms of programming EVER conceived: CGI2 programming.

Looks to me like it suggests alternatives to the module CGI.pm rather than CGI in general.

Hey!

You seem to be conflating the Perl module CGI.pm and the CGI protocol, it's a common and easy mistake to make. CGI::Alternatives is advice against the former, not the latter, like it states in the very first line of its documentation.

I've already talked about CGI.pm at length in various places, so won't go into it here in more detail¹.

I will say that I'm happy to audit, profile, and fix your CGI.pm based public facing applications' security holes and bugs for a *very* reasonable rate.

And, as others have said, patches are still welcome (despite what the CONTRIBUTING file says, as that is there to discourage people with big ideas).

Cheers!

Lee Johnson (current maintainer, with Dr. Lincoln Stein's full blessing, of the CGI.pm Perl module).

Seriously though, I'm at TPC in Glasgow this year, and the London and Swiss Perl workshops if you want to talk more.

1. For example: https://leejo.github.io/2016/02/22/all_software_is_legacy/

I agree, but I also agree to disagree. Telling people to not respond after posting such a storng post is not going to work. People will respond.

Breaking a long existing module is not done in my opinion. If someone thinks he or she can do better, then they can write their own module. One of the strong things of CPAN is that everyone is free to decide whatever module they want to use. And I think that you are right that this way that choice is taken away. However if it is decided that a module is no longer core, well that is up to 'them'.

Data::Dumper has been in core since 5.005 and isn't planned to go away.

File::Slurp has problems, but there are alternatives, but that's probably something you don't like to hear about Perl modules.

($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
[download]

I did say corelist as you point out but was thinking perl should be able to dump data structures with a core function. But I know who's in charge so it's just my much-less informed opinion, from a purely practical standpoint of always having to add Data::Dumper when things go awry. If this was wrong they probably wouldn't have bundled dumping into Perl6. I have beaten File::Slurp to death (also core perl6 functionality afaik) and the only time it failed was write_file with 2GB of data (syswrite error). I just wish Perl5 had perfect versions of read_dir, read_file and write_file to expedite what's usually done with readdir, open and print.

I agree with separating super-duper HTML production from CGI but it would be useful to have some basic stuff in there for quick printing out something. Maybe freeze existing HTML functionality in CGI.pm and that's it. Forcing templates on people is not the right approach although templates helped my productivity enormously.

Otherwise I agree with the poster. ALTHOUGH I dont have much of commercial experience deploying CGI.pm based apps and bearing the responsibility for security etc. Neither have I built an app and then found that CGI.pm has changed so much that my app is not working anymore and I have to re-write it. I would not like it much either, but that's how the business process in the world is right now: make obsolete and re-write.

Can anyone elaborate on any security risks posed by CGI.pm and if these are solved with alternatives? I kept reading that CGI.pm is insecure and alternatives is the way to go in the modern era ... but can anyone substantiate these claims?

Any other points to compare CGI.pm with alternatives?

I always thought the criticisms against CGI were lame, but using the later tools is so much more enjoyable that it's hard to care all that much. Nothing against OP, do whatever you want.

List flattening made a guy really mad and he did some videos at a conference. To me, his argument boils down to: List flattening is a bad language design choice because it is easily misunderstood by reasonably well trained programmers. I'm sure there was more, but that is what I got out of it.

I could not find a video referencing CGI that did not use the f word extensively. Sorry about that. That in itself is kind of funny though.

• Stop using Perl Video
• Stop Using Perl - discussion
• Stop Using Perl pt. 2 - more
• SawyerX - CGI Must die

Through the list of links you posted above I came across this:

• PacSec Hype Security Team: CGI.pm param injection which from what I understand the vulnerability comes when parsing a request with multiple same-name params. Perl's list/hash idiosyngracies be what they may makes it possible to create a hash of parameters which is not what one had in mind.
• and then this Re: Stop Using Perl :

  "... But you know whats even more amazing? They patched CGI.pm to warn about this ..."

Otherwise I agree with the poster. ALTHOUGH I dont have much of commercial experience deploying CGI.pm based apps and bearing the responsibility for security etc.

It was this false assumption that we're all using CGI.pm in ways that cause Perlmonks to run and hide their children (Matt's) that caused it's ejection from corelist and mutilation on CPAN. These days I usually use CGI::Simple::Standard anyway but CGI was exceptionally handy for writing portable (corelist) local administrative programs that don't endure the Internet. It's also capable of cranking out HTML under control of Perl to create things like dynamic templates and static resources in background processes run by cron that might hit a database once a minute or more to serve static resources rather than let live users make real requests that could range from 0 to Infinity per second... From what I can see there are still 3 modules on the corelist that generate HTML (and a lot more) but only from POD! With templates written in POD the Pod modules can crank out everything from HTML, XHTML, XML, RTF, man, etc. Hopefully they're SECURE! :-)

"...If you do NOT agree please DO NOT..."

Don't you ever tell me to shut up.

«The Crux of the Biscuit is the Apostrophe»

perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

I realize Perl is probably your first language but in English you were asked very nicely (PLEASE) to not hijack the thread in order to evangelize against the Common Gateway Interface. Of course you are free to ignore polite requests. Apologies if this was not clear in the OP.

This is not how discussion works...

I understand and agree. That's why I put this in Meditations rather than Discussion. I don't really need any more "discussion" of how much CGI sucks when I use it every day to kick ass. Anyway the monks will do what they wish with this thread. These anti-people are brainwashed by working for corporations and following their ridiculous programming ideology of maximum fragmentation, to deliberately disempower programmers. I have been there, laughed at them, and walked away... but I don't like their wacky cults invading my playground.

One Script to rule them all, One Script to find them,
One Script to bring them all and in the darkness bind them

So people who disagree exclusively work for corporations? There will be no productive discussion in this thread.

Steve
--