in reply to Re^2: What are best practices for Fast CGI nowadays?
in thread What are best practices for Fast CGI nowadays?

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.

  • Comment on Re^3: What are best practices for Fast CGI nowadays?

Replies are listed 'Best First'.
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]

In Section Seekers of Perl Wisdom