Skip to content

Conversation

@robhancocksed
Copy link
Contributor

The default behavior for tcp::resolver::query uses the
address_configured flag, which only returns addresses if a non-loopback
address is available on the system. If this is called before a real network
interface is brought up, then resolution will fail and the server won't
be functional, even for requests on the loopback interface.

Explicitly set the flags to default so that the address_configured flag
is not specified. This allows the server to start up normally even when
the system has no active network interfaces.

The default behavior for tcp::resolver::query uses the
address_configured flag, which only returns addresses if a non-loopback
address is available on the system. If this is called before a real network
interface is brought up, then resolution will fail and the server won't
be functional, even for requests on the loopback interface.

Explicitly set the flags to default so that the address_configured flag
is not specified. This allows the server to start up normally even when
the system has no active network interfaces.
tcp::resolver resolver(service);
// #446: boost resolver does not recognize "+" as a host wildchar
tcp::resolver::query query = ("+" == m_host) ? tcp::resolver::query(m_port) : tcp::resolver::query(m_host, m_port);
tcp::resolver::query query = ("+" == m_host) ?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was going to make this same PR!

The following would be shorter if it compiled cleanly everywhere?

-    tcp::resolver::query query = ("+" == m_host) ? tcp::resolver::query(m_port) : tcp::resolver::query(m_host, m_port);
+    tcp::resolver::query query = ("+" == m_host) ? tcp::resolver::query(m_port, {}) : tcp::resolver::query(m_host, m_port, {});

@BillyONeal
Copy link
Member

Is there any way to test this? I don't really know what this code is doing and without tests I'm worried we will regress this scenario for you in the future.

@garethsb
Copy link
Contributor

This affects Boost.ASIO-based http_listener on a machine which doesn't currently have a non-loopback address. I suspect that makes it hard to test without the user intervention of disabling network interfaces.

Another report, with the same fix, here: https://stackoverflow.com/a/5976632

@BillyONeal
Copy link
Member

Right, I trust the fix, I don't trust myself or a future maintainer to not unfix :)

@garethsb
Copy link
Contributor

How can we help? :-)

@BillyONeal BillyONeal merged commit 36e030a into microsoft:master Jun 13, 2019
@BillyONeal
Copy link
Member

Thanks for your contribution!

garethsb added a commit to sony/nmos-cpp that referenced this pull request Jun 14, 2019
…ne that has no network interfaces configured

(cf. microsoft/cpprestsdk#1145)

(cherry picked from commit b7ff7e3d7b98c681673e4d4088b11147fbe7395e)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants