Learning to use the httpd error log to debug CGI programs
In all of the above examples, we call die only after having already sent the MIME header to the browser (with the built-in CGI.pm “header” method). Failing to do so can create all sorts of odd problems, and results in the dreaded message:
Server Error. The server encountered an internal error or misconfiguration and was unable to complete your request.
For example, running the following CGI program:
#!/usr/local/bin/perl5 -w use strict; # Check our syntax strictly use diagnostics; # Tell us how to fix mistakes use CGI; # Import the CGI module use CGI::Carp; # Create an instance of CGI my $query = new CGI; # Don't do very much die "This program crashed on purpose ";The above program dies upon reaching the last line, and inserts an appropriate message into the httpd error log. What will the user see on his or her browser? In the above example, the user will get the dreaded:
The server encountered an internal error or misconfiguration and was unable to complete your request.You can alleviate this problem by sending a MIME header before performing any serious computations:
#!/usr/local/bin/perl5 -w
use strict; # Check our syntax strictly
use diagnostics; # Tell us how to fix mistakes
use CGI; # Import the CGI module
use CGI::Carp;
# Create an instance of CGI
my $query = new CGI;
print $query->header("text/html");
# Don't do very much
die "This program crashed on purpose ";
Note: while the documentation for CGI::Carp claims to alleviate
this problem, experiments with the version installed on my system
(from early September 1996) didn't seem to work quite this way. I
thus suggest that you output MIME headers as close to the beginning
of your programs as possible, simply to alleviate such problems.
Despite the colorful language that might occur to you when your program produces an error message, good warnings and logs are extremely helpful when writing and debugging code. This is especially true for CGI programs, where much of the work takes place behind the scenes and the only output to the user comes via a web browser. Learn to use the httpd error log effectively, and while your programming problems certainly won't disappear, your mistakes should be easier to identify and correct.
Reuven M. Lerner has been playing with the Web since early 1993, when it seemed more like a fun toy than the world's Next Great Medium. He currently works from his apartment in Haifa, Israel as an independent Internet and Web consultant. When not working on the Web or informally volunteering with school-age children, he enjoys reading (on just about any subject, but especially computers, politics, and philosophy—separately and together), cooking, solving crossword puzzles, and hiking. You can reach him at reuven@the-tech.mit.edu or reuven@netvision.net.il.
- « first
- ‹ previous
- 1
- 2
- 3
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
| Dart: a New Web Programming Experience | May 07, 2013 |
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- New Products
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- Validate an E-Mail Address with PHP, the Right Way
- New Products
- Developer Poll
- Trying to Tame the Tablet




1 hour 5 min ago
1 hour 41 min ago
1 hour 42 min ago
1 hour 43 min ago
1 hour 44 min ago
1 hour 48 min ago
1 hour 49 min ago
2 hours 47 min ago
4 hours 6 min ago
7 hours 39 min ago