For info on CGI, `perldoc -q CGI':
How can I generate simple menus without using CGI or Tk? The http://www.perl.com/CPAN/authors/id/SKUNZ/perlmenu.v4.0.ta +r.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 i +ssues. It may be run several times per second. Given that each ti +me it runs it will need to be re-compiled and will often allocat +e a megabyte or more of system memory, this can be a killer. Compiling into C isn't going to help you because the proce +ss start-up overhead is where the bottleneck is. There are two popular ways to avoid this overhead. One sol +ution 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 interprete +r which pre-compiles your script and then executes it within + the same address space without forking. The Apache extension a +lso gives Perl access to the internal server API, so modules w +ritten in Perl can do just about anything a module written in C c +an. For more on mod_perl, see http://perl.apache.org/ With the FCGI module (from CPAN) and the mod_fastcgi modul +e (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 y +our system and on the way you write your CGI programs, so investigate them with care. See http://www.perl.com/CPAN/modules/by-category/15_World_Wide +_Web_H TML_HTTP_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 i +n the question on books. For problems and questions related to t +he 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 li +ne'', see these sources: WWW Security FAQ http://www.w3.org/Security/Faq/ Web FAQ http://www.boutell.com/faq/ CGI FAQ http://www.webthing.com/tutorials/cgifaq.html HTTP Spec http://www.w3.org/pub/WWW/Protocols/HTTP/ HTML Spec http://www.w3.org/TR/REC-html40/ http://www.w3.org/pub/WWW/MarkUp/ CGI Spec http://www.w3.org/CGI/ CGI Security FAQ http://www.go2net.com/people/paulp/cgi-security/sa +fe-cgi.txt Found in C:\Perl\lib\pod\perlfaq9.pod My CGI script runs from the command line but not the browser. (500 +Server Error) If you can demonstrate that you've read the following FAQs + and that your problem isn't something simple that can be easil +y answered, you'll probably receive a courteous and useful r +eply to your question if you post it on comp.infosystems.www.authoring.cgi (if it's something to d +o with HTTP, HTML, or the CGI protocols). Questions that appear t +o be Perl questions but are really CGI ones that are posted to comp.lang.perl.misc may not be so well received. The useful FAQs and related documents are: CGI FAQ http://www.webthing.com/tutorials/cgifaq.html Web FAQ http://www.boutell.com/faq/ WWW Security FAQ http://www.w3.org/Security/Faq/ HTTP Spec http://www.w3.org/pub/WWW/Protocols/HTTP/ HTML Spec http://www.w3.org/TR/REC-html40/ http://www.w3.org/pub/WWW/MarkUp/ CGI Spec http://www.w3.org/CGI/ CGI Security FAQ http://www.go2net.com/people/paulp/cgi-security/sa +fe-cgi.txt How can I get better error messages from a CGI program? Use the CGI::Carp module. It replaces "warn" and "die", pl +us the normal Carp modules "carp", "croak", and "confess" functio +ns 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-t +ime 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 cl +ient browser, which is nice for your own debugging, but might c +onfuse the end user. use CGI::Carp qw(fatalsToBrowser); die "Bad error here"; Even if the error happens before you get the HTTP header o +ut, the module will try to take care of this to avoid the drea +ded server 500 errors. Normal warnings still go out to the ser +ver error log (or wherever you've sent them with "carpout") wi +th the application name and date stamp prepended. How do I make sure users can't enter values into a form that cause m +y CGI script to do bad things? Read the CGI security FAQ, at http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.htm +l , and the Perl/CGI FAQ at http://www.perl.com/CPAN/doc/FAQs/cgi/perl-cgi-faq.html . In brief: use tainting (see perlsec), which makes sure tha +t data from outside your script (eg, CGI parameters) are never us +ed in "eval" or "system" calls. In addition to tainting, never u +se the single-argument form of system() or exec(). Instead, suppl +y the command and arguments as a list, which prevents shell glob +bing. 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 ST +DIN the number of bytes equal to CONTENT_LENGTH for POSTs, or +grab QUERY_STRING for decoding GETs. These programs are very po +orly written. They only work sometimes. They typically forget t +o 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 wit +h 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. Ple +ase 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 repeat +ed 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 U +RL once or multiple times. This is because the HTTP protocol definition says that a GET request may be cached by the br +owser, or server, or an intervening proxy. POST requests cannot b +e 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 comp +uter).
|
MJD says you can't just make shit up and expect the computer to know what you mean, retardo! ** The Third rule of perl club is a statement of fact: pod is sexy. |
In reply to Re: how html2text converter run in CGI
by PodMaster
in thread how html2text converter run in CGI
by ayob
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |