Re^2: What are best practices for Fast CGI nowadays?

This node falls below the community's threshold of quality. You may see it by logging in.

Replies are listed 'Best First'.
Re^3: What are best practices for Fast CGI nowadays? by mldvx4 (Friar) on Mar 28, 2018 at 08:32 UTC
I'm happy to say that I over-estimated the amount and nature changes in how Perl interacts with web servers. Specifically the most useful thing to know was that CGI::Fast supplements CGI. So once the script is up and running and in contact with the server, the familiar CGI module can be used. Once I got over that hump it was all good again. In some of the reading it was important to know to import the CGI::Fast first and CGI second so that if there is any colision, CGI wins.	[reply]
Re^4: What are best practices for Fast CGI nowadays? by Your Mother (Archbishop) on Mar 28, 2018 at 16:28 UTC
CGI::Fast first and CGI second so that if there is any colision, CGI wins. Unless you have a library conflict with broken installs which is actually pretty hard to manage (some things installed in one place and related others at a different version installed in another place). This is not an issue and you should not even load CGI because it is misleading. CGI::Fast has already done it internally. And it's backwards. First loaded, where code overlaps, wins, not second. (Update: to clarify, I mean code packages. Once loaded, they aren't reloaded without gymnastics.) From the CGI::Fast POD (and code, POD can lie) – CGI::Fast is a subclass of the CGI object created by CGI.pm.	[reply]