home | O'Reilly's CD bookshelfs | FreeBSD | Linux | Cisco | Cisco Exam  


19.9. Debugging the Raw HTTP Exchange

Problem

Your CGI script is misbehaving strangely with your browser, and you suspect something in the HTTP header is missing. You want to find out exactly what your browser is sending to the server in the HTTP header.

Solution

Create your own fake web server, and point your browser at it, as shown in Example 19.6 .

Example 19.6: dummyhttpd

#!/usr/bin/perl -w
# 

dummyhttpd - start an HTTP daemon and print what the client sends

use strict;
use HTTP::Daemon;  # need LWP-5.32 or better

my $server = HTTP::Daemon->new(Timeout => 60, LocalPort => 8989);
print "Please contact me at: <URL:", $server->url, ">\n";

while (my $client = $server->accept) {
  CONNECTION:
    while (my $answer = $client->get_request) {
        print $answer->as_string;
        $client->autoflush;
      RESPONSE:
        while (<STDIN>) {
            last RESPONSE   if $_ eq ".\n";
            last CONNECTION if $_ eq "..\n";
            print $client $_;
        }
        print "\nEOF\n";
    }
    print "CLOSE: ", $client->reason, "\n";
    $client->close;
    undef $client;
}

Discussion

It's hard to keep track of which versions of all the different browsers still have which bugs. The fake server program can save you days of head scratching, because sometimes a misbehaving browser doesn't send the server the right thing. Historically, we have seen aberrant browsers lose their cookies, mis-escape a URL, send the wrong status line, and do other even less obvious things.

To use the fake server, it's best to run it on the same machine as the real server. That way your browser will still send it any cookies destined for that domain. Then instead of pointing your browser at:

http://somewhere.com/cgi-bin/whatever

use the alternate port given in the new constructor above. You don't need to be the superuser to run the server if you use the alternate port.

http://somewhere.com:8989/cgi-bin/whatever

If you convince yourself that the client is behaving properly but wonder about the server, it's easiest to use the telnet program to manually talk to the remote server.

% telnet www.perl.com 80




GET /bogotic HTTP/1.0








<blank line here>








HTTP/1.1 404 File Not Found








Date: Tue, 21 Apr 1998 11:25:43 GMT








Server: Apache/1.2.4








Connection: close








Content-Type: text/html









<HTML><HEAD>








<TITLE>404 File Not Found</TITLE>








</HEAD><BODY>








<H1>File Not Found</H1>








The requested URL /bogotic was not found on this server.<P>








</BODY></HTML>



If you have LWP installed on your system, you can use the GET alias for the lwp-request program. This will follow any redirection chains, which can shed light on your problem. For example:

% GET -esuSU http://mox.perl.com/perl/bogotic




GET http://language.perl.com/bogotic








Host: mox.perl.com








User-Agent: lwp-request/1.32









GET http://mox.perl.com/perl/bogotic --> 302 Moved Temporarily








GET http://www.perl.com/perl/bogotic --> 302 Moved Temporarily








GET http://language.perl.com/bogotic --> 404 File Not Found








Connection: close








Date: Tue, 21 Apr 1998 11:29:03 GMT








Server: Apache/1.2.4








Content-Type: text/html








Client-Date: Tue, 21 Apr 1998 12:29:01 GMT








Client-Peer: 208.201.239.47:80








Title: Broken perl.com Links









<HTML>








<HEAD><TITLE>An Error Occurred</TITLE></HEAD>








<BODY>








<H1>An Error Occurred</h1>








404 File Not Found








</BODY>








</HTML>









See Also

The documentation for the standard CGI module; Recipe 19.10