Hello Joe,
I humbly disagree. Name resolution doesn't require blocking, as so many of the implementations do -- like The [ISC] Bind, for example.
It's horribly, and unnecessairly inefficient. Lookups, more often than not, only require mere milliseconds. I became frustrated with the DNS (software) available, and looked to create one from scratch. I nearly finished it, but didn't. But out of it, I created an asynchronous resolver. On standard CPE, it easily resolves 255 addresses in ~2 seconds. How many hiawatha installs have that kind of traffic? My point is; it seems that most anyone that thinks the overhead of name resolution is too high. Have little real understanding of whats actually required, and involved. Or perhaps more accurately; their experiences with name resolution, has been with bad implementations, where the requests were blocking calls. Meaning; everything came to a stop, until the request was answered.
Anyway, it appears that you've answered my question, Joe. Hiawatha doesn't perform any kind of IP-to-HOST function. I tested
further, and found that the only way I was able to gather the HOST name
$ENV{REMOTE_HOST}
of the connecting client, was to implement a function of my own, in Perl:
use Socket;
...
my $remote_ip = $ENV{REMOTE_ADDR};
# a re-implementation of CGI: the Common Gateway Interface (http://hoohoo.ncsa.uiuc.edu/cgi/overview.html)
# the following is a blocking request, but a reasonable timeout can be easily added
my $remote_host = gethostbyaddr(inet_aton($remote_ip), AF_INET);
It's the only way I can effectively populate the CGI environment variable that was created, and available with the first HTTPd ever created: NCSA HTTPD. Anyway, it looks like CGI isn't fully available in Hiawatha. Or at least not fully
exposed to the user. I guess I'll have to hack on the Hiawatha code, and create a slightly more robust version.
Thanks Joe, for taking the time to reply!
--Chris