[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LYNX-DEV Re: DNS lookups revisited
From: |
Foteos Macrides |
Subject: |
Re: LYNX-DEV Re: DNS lookups revisited |
Date: |
Wed, 24 Dec 1997 10:18:28 -0500 (EST) |
Richard Levitte - VMS Whacker <address@hidden> wrote:
>[...]
>I certainly hope gethostbyname() return a struct hostent *. I imagine
>the Multinet implementation returns such a thing with a NULL address
>list, correct?
>
>According to all docs I can find, gethostbyname() should return NULL on
>failure. The following could be found in the OpenBSD 2.1 man page for
>gethostbyname():
>
> DIAGNOSTICS
> Error return status from gethostbyname(), gethostbyname2(), and
> gethostbyaddr() is indicated by return of a null pointer. The external
> integer h_errno may then be checked to see whether this is a temporary
> failure or an invalid or unknown host.
>
> The variable h_errno can have the following values:
>[...]
> TRY_AGAIN This is usually a temporary error and means that the lo-
> cal server did not receive a response from an authorita-
> tive server. A retry at some later time may succeed.
>[...]
Hmm... There's that longstanding glitch in Lynx of it failing
occassionally on gethostbyname() calls, and then working if you try again
for the same host. It's not checking h_error, so I did this quickie hack
in HTParseInet() of HTTCP.c:
[...]
phost = gethostbyname(host); /* See netdb.h */
if (!phost && h_errno == TRY_AGAIN) {
sleep(1);
phost = gethostbyname(host);
}
I'm not sure how best to structure that check, or how to do it for the
forked gethostbyname() calls, but if that intermittent problem goes
away, this might be the explanation, and an appropriate check should
be added to all the gethostbyname() calls.
Fote
=========================================================================
Foteos Macrides Worcester Foundation for Biomedical Research
address@hidden 222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================