I came across a problem in Protocols.HTTP.Session last week. It seems the Session module uses gethostbyname() to perform DNS lookups and then randomly selects one of the returned IP addresses. This can cause problems under 7.7 if the selected IP is an IPv6 address and the host doesn't have IPv6 connectivity.
Rather than rewriting the Session module DNS lookup, I would like to add an optional argument to the gethostbyname() method to allow selection of the types to be returned.
Any thoughts?
there is a gnu extension in the glibc which works like that: struct hostent *gethostbyname2(const char *name, int af);
so your suggestion sounds just right.
greetings, martin.
How would such an optional argument help in this case? Protocols.HTTP.Session can't very well know what argument to use.
(Not that I have anything against the suggestion of course; something like Protocols.DNS.gethostbyname("www.netbsd.org", ({T_A, T_A6})) to get only A and A6 records (and no AAAA) should be ok.)
In itself, it wouldn't help at all, I just highlighted the first part of the problem. We still need to modify the Session class as well. I don't, however, have a solution for that with which I'm satisfied.
I think it's a feature to be able to use IPv6, if it is available, so I don't want to change the Session class to simply ask for IPv4 addresses. If you have any suggestions on how to decide if IPv6 is available or not, feel free to share.
I can't see any reference to gethostbyname in Session. In Query, on the other hand...
It's quite possible that Session *should* contain the DNS lookup sequence, so it can be easily hooked into, though. It already contains a hostname lookup cache, but rather roughly used by the Query objects...
True, it's the Query class that does the lookup. My bad.
Still, it should be fixed so that it doesn't resolve IPv6 addresses when they can't be used.
The proper fix ought to be that it tries all the IPs until it reaches one that works (consider the case of DNS IPv4 round-robin where one of the hosts is down).
Yes, that would be a much better solution than the random selection currently used. Shouldn't be too hard to implement, so I'll try to whip up a patch sometime this week.
pike-devel@lists.lysator.liu.se