ch9.htm

美国Macmillan出版社编写的Perl教程《Perl CGI Web Pages for WINNT》

inside the Perl script. When a server returns an error like this:
<P>
This server has encountered an internal error which prevents it
from fulfilling your request.
<P>
it might not be that your Perl script isn't running, which you
should check first, but that the HTML is interfering. If your
script is running fine, then look over your HTML document for
misused, or conflicting tags; missing &quot;&lt;&quot; or &quot;&gt;&quot;
symbols; or even unsupported HMTL tags.
<P>
Use a browser that displays incorrect HTML to find the problem
areas. Some common HTML errors are as follows:
<UL>
<LI>Not starting and ending HTML documents with the &lt;HTML&gt;
and &lt;/HTML&gt; tags.
<LI>&lt;HEAD&gt; or &lt;BODY&gt; tags that are not closed with
the coresponding &lt;/HEAD&gt; and &lt;/BODY&gt; tags.
<LI>Incorrect punctuation, often obscured in a Perl script by
Perl's own punctuation.
<LI>Using non-ASCII characters in the HTML output.
</UL>
<P>
If you can't find a browser that will display HTML errors, then
you can use the MIME header
<BLOCKQUOTE>
<PRE>
Content-type: text/ascii
</PRE>
</BLOCKQUOTE>
<P>
to force the browser to display HTML. If you are familar with
telnet you&nbsp;can also use this protocol to find out if HTML
is your problem.
<P>
Using telnet, you can view the HTML document and not use the browser
at all. The first step is to begin a telnet session with your
HTTP service. You can do this by using the command
<BLOCKQUOTE>
<PRE>
telnet your_site_name.com 8&Oslash;
</PRE>
</BLOCKQUOTE>
<P>
where your_site_name is the name of the site with the HTML document
to be checked and 80 is the HTTP port. The HTTP port may be different,
but it is usually 80. Once a connection has been established,
use the GET command to find the HTML document, like this:
<BLOCKQUOTE>
<PRE>
GET perl/directory/the_file HTTP/1.0
</PRE>
</BLOCKQUOTE>
<P>
where perl/directory/ is the pathname and the_file is the Perl
script containing the HTML document being tested.
<P>
This command will cause the Perl script to execute and the HTML
to print out line by line on the telnet terminal screen.
<H3><A NAME="TheMIMEHeader">
The MIME Header</A></H3>
<P>
As mentioned in the chapter on the CGI, MIME specifications are
very important in determining the type of output. Having the right
MIME header sent by your script can determine its success or failure,
so close attention must be paid here. The MIME header should look
like this:
<BLOCKQUOTE>
<PRE>
Content-type: text/html
&lt;HTML&gt;
&lt;HEAD&gt;
the rest of your HTML document...
</PRE>
</BLOCKQUOTE>
<P>
A common error is to leave a blank line between the MIME header,
&quot;Content-type:&quot; and the first HTML tag, &quot;&lt;HTML&gt;.&quot;
Remember to include at least one line of text, like the &lt;HTML&gt;
tag, after the MIME header when you are testing it, because some
browsers will read only MIME headers that are followed by text.
<H3><A NAME="ProblemswithUserData">
Problems with User Data</A></H3>
<P>
There may be a problem with the data being returned to the Perl
script from the user, be it from an HTML form or a QUERY_STRING
environmental variable. To check this data you can pass it through
a simple Perl script like this:
<BLOCKQUOTE>
<PRE>
#!/usr/bin/perl
# datarc.pl
MAIN: {
     print &quot;Content-type: text/html\n\n&quot;;
     print &quot;&lt;HTML&gt;&lt;HEAD&gt;&lt;TITLE&gt;Return Data Display&lt;/TITLE&gt;&quot;;
     print &quot;&lt;/HEAD&gt;&lt;BODY&gt;&quot;;
     while (($a,$b) = each %ENV) {
          print &quot;$a=$b&lt;BR&gt;\n&quot;;
     }
     print &quot;&lt;/BODY&gt;&lt;/HTML&gt;&quot;;
     exit &Oslash;;
}
</PRE>
</BLOCKQUOTE>
<P>
which will list all the properties of the CGI environment. A typical
response from this script might include these environmental variables:
<BLOCKQUOTE>
<PRE>
OS=Windows_NT
GATEWAY_INTERFACE=CGI/1.1
DOCUMENT_ROOT=http/lib/html
REMOTE_ADDR=134.56.1&Oslash;3.1
SERVER_PROTOCOL=HTTP/1.&Oslash;
REQUEST_METHOD=GET
SCRIPT_NAME=data_return_check.pl
SERVER_NAME=www.atlantis.com 
</PRE>
</BLOCKQUOTE>
<P>
where all the environmental variables involved with the server,
CGI, and script are returned (a list that is actually much longer
than the example here).
<P>
Take special note of the following returns:
<UL>
<LI>The HTTP software. Different services handle the same data
differently.
<LI>The method of request. POST is to be used with most forms,
but GET is the default if the method is not specified.
<LI>Both the QUERY_STRING and CONTENT_LENGTH variables note the
content of the GET request. You must use the GET method to request
the script, which is above the Action of the form.
<LI>The PATH, which can be checked to see if you are accessing
the right file for debugging.
</UL>
<P>
Each of these returns, as well as the other environmental variables
returned, can provide debugging help if you know what to look
for.
<H3><A NAME="CheckingNameValuePairs">
Checking Name/Value Pairs</A></H3>
<P>
Debugging also can be accomplished by splitting key/value pairs
in an associative array. It is these data pairs-which are called
name/value pairs in the CGI-that are used to move information
from the client to the server via an HTML form.
<P>
For a thorough check of user input you can examine the associative
array into which this data is stored. By calling up the key/value
pairs, or the name/value pairs, of the associative array you can
check each element. You can call this information by splitting
the CGI name/value pairs and then displaying the data. Please
note that this is just an excerpt from a script. This should be
used at the beginning of your CGI script, after print &quot;Content-type:
text/html\n\n&quot;; but before the script does anything. Otherwise,
insert the #!/usr/bin/perl line and all the HTML form tags at
the beginning of this snippet. To split the name/value pairs you
can use this script snippet:
<BLOCKQUOTE>
<PRE>
foreach $key (keys(%ASSOC)) {
print &quot;$key = $ASSOC{$key}\n&quot;;
}     
</PRE>
</BLOCKQUOTE>
<P>
where the user data is returned to the associative array %ASSOC,
and the literal representation of this associatve array is then
put into the scalar variable $key.
<P>
To display the name/value pairs in the array, another snippet
of Perl (with the same conditions as the above snippet) is effective:
<BLOCKQUOTE>
<PRE>
print &quot;&lt;html&gt;&lt;head&gt;&lt;title&gt;\n&quot;;
print &quot;Name/Value Listing\n&quot;;
print &quot;&lt;/title&gt;&lt;body&gt;&lt;h2&gt;/n&quot;;
while (($key,$value) = each %form_data {
     print &quot;$key = $value&lt;BR&gt;\n&quot;;
print &quot;&lt;/h2&gt;&lt;/body&gt;&lt;/hmtl&gt;\n&quot;;
</PRE>
</BLOCKQUOTE>
<P>
where each name/value pair will be presented as an equation with
the key/name on the left side and the value on the right in an
HTML document, as shown in Figure 9.2.
<P>
<A HREF="f9-2.gif" tppabs="http://210.32.137.15/ebook/PC%20Magazine%20Programming%20Perl%205.0%20CGI%20Web%20Pages%20for%20Microsoft%20Windows%20NT/f9-2.gif"><B>Figure 9.2 :</B> <I>A return of name/value pairs</I>.</A>
<H3><A NAME="ThePerlCommandLine">
The Perl Command Line</A></H3>
<P>
By accessing your Perl script on the command line of perl.exe,
you can test your script in the CGI environment without having
to involve the HTTP server you are using.
<H4>How to Test without an HTTP Server</H4>
<P>
It is better to test your script without involving your HTTP server
so that you can find the precise place where your script breaks
down. You also will be able to see the error messages returned
by the CGI in their entirety; view the whole of the script's HTML
output even if it isn't written properly, or if it is missing
the necessary MIME headers; and be able to sidestep any errors
originating in your HTTP server.
<P>
You can test the request for data cycle that your script creates
at the command line if you are using the GET method instead of
the POST method on your HTML form. When you are using the GET
method, then the environmental variable REQUEST_METHOD should
have the value GET and QUERY_STRING should have the value of the
user specified data.
<P>
The key to testing your GET method is simulating the way data
used for the test is being sent to the HTTP server in QUERY_STRING.
To do this, you place an &quot;&amp;&quot; symbol between all
variable/value pairs, and the &quot;=&quot; symbol between the
variables and their values. This data is what is held in the QUERY_STRING
for the test. To create a sample of this modified data, like that
used in Figure 9.1, you would take the following form-entered
data
<BLOCKQUOTE>
<PRE>
First Name: Pierre
     Last Name: Burton
     Street Address: 32 Pitty-pat Lane
     City: Hope
     State: British Columbia
     Telephone: 6&Oslash;4 621 6467
     Occupation: Living Legend 
</PRE>
</BLOCKQUOTE>
<P>
and add the &quot;&amp;&quot; and &quot;=&quot; symbols to get
these variable values:
<BLOCKQUOTE>
<PRE>
REQUEST_METHOD = GET
     QUERY_STRING = FirstName=Pierre&amp;Last+Name=Burton&amp;Street Address=32Pitty-pat
	 +Lane&amp;City=Hope&amp;State=BritishColumbia&amp;Telephone=6&Oslash;455556467
	 &amp;Occupation=Living+Legend
</PRE>
</BLOCKQUOTE>
<P>
where you will notice the whitespaces in the form's reply are
preserved in the QUERY_STRING.
<P>
To give QUERY_STRING the test value, use the setenv operator with
double quotes, so the example would then look like this:
<BLOCKQUOTE>
<PRE>
setenv REQUEST_METHOD GET
     setenv QUERY_STRING &quot;First Name=Pierre\&amp;Last Name=Burton\&amp;Street Address=32
	 Pitty-pat Lane\&amp;City=Hope\&amp;State=British Columbia\&amp;Telephone=6&Oslash;
	 4 555 6467\&amp;Occupation=Living Legend&quot;
</PRE>
</BLOCKQUOTE>
<P>
where you will notice the use of the backslash to tell Perl the
&quot;&amp;&quot; symbol is performing a special task in this
line.
<P>
To see if you can succeed in adding these two environmental variables
you can type &quot;setenv&quot; by itself on the command line.
This will produce a full list of all the environmental variables
currently available-including the two you just added.
<H3><A NAME="TheServerErrorLog">
The Server Error Log</A></H3>
<P>
Checking your HTTP service's error log can provide another source
of information regarding script failures with the CGI. This log