Found in G:\Perl\lib\pod\perlfaq3.pod
  How can I generate simple menus without using CGI or Tk?
            The http://www.cpan.org/authors/id/SKUNZ/perlmenu.v4.0.tar.gz
            module, which is curses-based, can help with this.

  How can I make my CGI script more efficient?
            Beyond the normal measures described to make general Perl
            programs faster or smaller, a CGI program has additional issues.
            It may be run several times per second. Given that each time it
            runs it will need to be re-compiled and will often allocate a
            megabyte or more of system memory, this can be a killer.
            Compiling into C isn't going to help you because the process
            start-up overhead is where the bottleneck is.

            There are two popular ways to avoid this overhead. One solution
            involves running the Apache HTTP server (available from
            http://www.apache.org/ ) with either of the mod_perl or
            mod_fastcgi plugin modules.

            With mod_perl and the Apache::Registry module (distributed with
            mod_perl), httpd will run with an embedded Perl interpreter
            which pre-compiles your script and then executes it within the
            same address space without forking. The Apache extension also
            gives Perl access to the internal server API, so modules written
            in Perl can do just about anything a module written in C can.
            For more on mod_perl, see http://perl.apache.org/

            With the FCGI module (from CPAN) and the mod_fastcgi module
            (available from http://www.fastcgi.com/ ) each of your Perl
            programs becomes a permanent CGI daemon process.

            Both of these solutions can have far-reaching effects on your
            system and on the way you write your CGI programs, so
            investigate them with care.

            See
            http://www.cpan.org/modules/by-category/15_World_Wide_Web_HTML_H
            TTP_CGI/ .

            A non-free, commercial product, ``The Velocity Engine for
            Perl'', (http://www.binevolve.com/ or
            http://www.binevolve.com/velocigen/ ) might also be worth
            looking at. It will allow you to increase the performance of
            your Perl programs, running programs up to 25 times faster than
            normal CGI Perl when running in persistent Perl mode or 4 to 5
            times faster without any modification to your existing CGI
            programs. Fully functional evaluation copies are available from
            the web site.

  Where can I learn about CGI or Web programming in Perl?
            For modules, get the CGI or LWP modules from CPAN. For
            textbooks, see the two especially dedicated to web stuff in the
            question on books. For problems and questions related to the
            web, like ``Why do I get 500 Errors'' or ``Why doesn't it run
            from the browser right when it runs fine on the command line'',
            see the troubleshooting guides and references in perlfaq9 or in
            the CGI MetaFAQ:

                    http://www.perl.org/CGI_MetaFAQ.html

Found in G:\Perl\lib\pod\perlfaq9.pod
  What is the correct form of response from a CGI script?
            (Alan Flavell <flavell+www@a5.ph.gla.ac.uk> answers...)

            The Common Gateway Interface (CGI) specifies a software
            interface between a program ("CGI script") and a web server
            (HTTPD). It is not specific to Perl, and has its own FAQs and
            tutorials, and usenet group, comp.infosystems.www.authoring.cgi

            The original CGI specification is at:
            http://hoohoo.ncsa.uiuc.edu/cgi/

            Current best-practice RFC draft at: http://CGI-Spec.Golux.Com/

            Other relevant documentation listed in:
            http://www.perl.org/CGI_MetaFAQ.html

            These Perl FAQs very selectively cover some CGI issues. However,
            Perl programmers are strongly advised to use the CGI.pm module,
            to take care of the details for them.

            The similarity between CGI response headers (defined in the CGI
            specification) and HTTP response headers (defined in the HTTP
            specification, RFC2616) is intentional, but can sometimes be
            confusing.

            The CGI specification defines two kinds of script: the "Parsed
            Header" script, and the "Non Parsed Header" (NPH) script. Check
            your server documentation to see what it supports. "Parsed
            Header" scripts are simpler in various respects. The CGI
            specification allows any of the usual newline representations in
            the CGI response (it's the server's job to create an accurate
            HTTP response based on it). So "\n" written in text mode is
            technically correct, and recommended. NPH scripts are more
            tricky: they must put out a complete and accurate set of HTTP
            transaction response headers; the HTTP specification calls for
            records to be terminated with carriage-return and line-feed, i.e
            ASCII \015\012 written in binary mode.

            Using CGI.pm gives excellent platform independence, including
            EBCDIC systems. CGI.pm selects an appropriate newline
            representation ($CGI::CRLF) and sets binmode as appropriate.

  My CGI script runs from the command line but not the browser.  (500 Server Error)
            Several things could be wrong. You can go through the
            "Troubleshooting Perl CGI scripts" guide at

                    http://www.perl.org/troubleshooting_CGI.html

            If, after that, you can demonstrate that you've read the FAQs
            and that your problem isn't something simple that can be easily
            answered, you'll probably receive a courteous and useful reply
            to your question if you post it on
            comp.infosystems.www.authoring.cgi (if it's something to do with
            HTTP or the CGI protocols). Questions that appear to be Perl
            questions but are really CGI ones that are posted to
            comp.lang.perl.misc are not so well received.

            The useful FAQs, related documents, and troubleshooting guides
            are listed in the CGI Meta FAQ:

                    http://www.perl.org/CGI_MetaFAQ.html

  How can I get better error messages from a CGI program?
            Use the CGI::Carp module. It replaces "warn" and "die", plus the
            normal Carp modules "carp", "croak", and "confess" functions
            with more verbose and safer versions. It still sends them to the
            normal server error log.

                use CGI::Carp;
                warn "This is a complaint";
                die "But this one is serious";

            The following use of CGI::Carp also redirects errors to a file
            of your choice, placed in a BEGIN block to catch compile-time
            warnings as well:

                BEGIN {
                    use CGI::Carp qw(carpout);
                    open(LOG, ">>/var/local/cgi-logs/mycgi-log")
                        or die "Unable to append to mycgi-log: $!\n";
                    carpout(*LOG);
                }

            You can even arrange for fatal errors to go back to the client
            browser, which is nice for your own debugging, but might confuse
            the end user.

                use CGI::Carp qw(fatalsToBrowser);
                die "Bad error here";

            Even if the error happens before you get the HTTP header out,
            the module will try to take care of this to avoid the dreaded
            server 500 errors. Normal warnings still go out to the server
            error log (or wherever you've sent them with "carpout") with the
            application name and date stamp prepended.

  How do I make sure users can't enter values into a form that cause my CGI script to do bad things?
            See the security references listed in the CGI Meta FAQ

                    http://www.perl.org/CGI_MetaFAQ.html

  How do I decode a CGI form?
            You use a standard module, probably CGI.pm. Under no
            circumstances should you attempt to do so by hand!

            You'll see a lot of CGI programs that blindly read from STDIN
            the number of bytes equal to CONTENT_LENGTH for POSTs, or grab
            QUERY_STRING for decoding GETs. These programs are very poorly
            written. They only work sometimes. They typically forget to
            check the return value of the read() system call, which is a
            cardinal sin. They don't handle HEAD requests. They don't handle
            multipart forms used for file uploads. They don't deal with
            GET/POST combinations where query fields are in more than one
            place. They don't deal with keywords in the query string.

            In short, they're bad hacks. Resist them at all costs. Please do
            not be tempted to reinvent the wheel. Instead, use the CGI.pm or
            CGI_Lite.pm (available from CPAN), or if you're trapped in the
            module-free land of perl1 .. perl4, you might look into
            cgi-lib.pl (available from http://cgi-lib.stanford.edu/cgi-lib/
            ).

            Make sure you know whether to use a GET or a POST in your form.
            GETs should only be used for something that doesn't update the
            server. Otherwise you can get mangled databases and repeated
            feedback mail messages. The fancy word for this is
            ``idempotency''. This simply means that there should be no
            difference between making a GET request for a particular URL
            once or multiple times. This is because the HTTP protocol
            definition says that a GET request may be cached by the browser,
            or server, or an intervening proxy. POST requests cannot be
            cached, because each request is independent and matters.
            Typically, POST requests change or depend on state on the server
            (query or update a database, send mail, or purchase a computer).