Unexpected behavior in reverse lookup (asio resolver)
When performing a reverse lookup of an address: *r->async_resolve( boost::asio::ip::tcp::resolver::endpoint_type( adr, 80 ) ...* the address itself is returned (as string), when the name of the host cannot be found. I would expect an error/exception, telling me this instead. Consider the following (custom class which does both): *Resolver::resolve< ResolverClass >( &rc, "www.yahoo.com", 1 ); Resolver::resolve< ResolverClass >( &rc, "8.8.8.8", 2 ); Resolver::resolve< ResolverClass >( &rc, "none.exist.end", 3 ); Resolver::resolve< ResolverClass >( &rc, "2.18.77.109", 4 ); Resolver::resolve< ResolverClass >( &rc, "198.252.206.16", 5 ); Resolver::resolve< ResolverClass >( &rc, "234.255.173.123", 6 );* And the result: *1: hostname: www.yahoo.com, address: 87.248.98.7, error: 1: hostname: www.yahoo.com, address: 87.248.98.8, error: 2: hostname: google-public-dns-a.google.com, address: 8.8.8.8, error: 3: hostname: , address: 0.0.0.0, error: Host not found (authoritative) 4: hostname: a2-18-77-109.deploy.static.akamaitechnologies.com, address: 2.18.77.109, error: 5: hostname: stackoverflow.com, address: 198.252.206.16, error: 6: hostname: 234.255.173.123, address: 234.255.173.123, error:* 2 is looking up of "8.8.8.8", which of course can be found and returns the google.com entry. Likewise, 4 and 5 can be found and return the correct result. *Nr. 6, however, is a non-existent ip-address. As you can see, instead of an error, the address itself is returned when calling "endpoint_iterator->host_name();".* This is unexpected and (I think) undocumented. It can be easily detected by testing if host_name returns an address, but this would require another (test) conversion; as a result you'd end up with forth&back conversions. Wouldn't it be better, if the reverse lookup returned an error/exception, if the name of the host cannot be found? This would be more consistent with the "Host not found (authoritative)" error in example 3. -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html
On Tue, 18 Sep 2018 at 16:36, LC via Boost
Wouldn't it be better, if the reverse lookup returned an error/exception, if the name of the host cannot be found? This would be more consistent with the "Host not found (authoritative)" error in example 3.
0.0.0.0 is not a valid internet address, as opposed to a not-assigned one, so consistency does not apply. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*
On 19/09/2018 01:36, LC via Boost wrote:
When performing a reverse lookup of an address:
*r->async_resolve( boost::asio::ip::tcp::resolver::endpoint_type( adr, 80 ) ...*
the address itself is returned (as string), when the name of the host cannot be found. I would expect an error/exception, telling me this instead. [...] *Nr. 6, however, is a non-existent ip-address. As you can see, instead of an error, the address itself is returned when calling "endpoint_iterator->host_name();".* This is unexpected and (I think) undocumented. It can be easily detected by testing if host_name returns an address, but this would require another (test) conversion; as a result you'd end up with forth&back conversions.
I don't know if this is the reason, but most code will prefer displaying and using the hostname (when available), but when no hostname is available then the address works just as well. Similarly when async_resolve is asked to find the address for a hostname, you can supply a "hostname" which is actually an address, and this simply returns the same address without error, which is what most people want. This allows code to just use a resolve -> connect chain in all cases regardless of whether the input hostname is actually an address or not. Or to put it another way, an address is also a valid hostname.
On Wed, 19 Sep 2018 at 06:55, Gavin Lambert via Boost
Or to put it another way, an address is also a valid hostname.
This is also consistent with the error on 0.0.0.0 as this does not constitute a valid address, thus this "an address is also a valid hostname" is not true, in that case (and there are more, it's well defined). degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*
You might want to document this behavior. -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html
participants (3)
-
degski -
Gavin Lambert -
LC