On 27. 7. 25 05:25, Branko Čibej wrote:
On 26. 7. 25 22:11, br...@apache.org wrote:
Author: brane
Date: Sat Jul 26 20:11:05 2025
New Revision: 1927485
Log:
In the Unbound resolver, finally convert the results to apr_sockaddr_t.
[...]
@@ -60,8 +63,8 @@
* - Wake the poll/select in serf_context_run() when new resolve
* results are available.
*
- * TODO for Unbound:
- * - Convert unbound results to apr_sockaddr_t.
+ * - Unbound: Detect when the "hostname" is actually a stringified
IP address.
+ * The resolver doesn't handle that, so we have to short-circuit
that case.
*/
As I wrote above, the Unbound resolver doesn't know what to do when
given an IPv4 of IPv6 address as the "hostname". Obviously this needs
to be handled in Serf before/instead of calling Unbound. APR handles
this, and has its own apr_inet_pton() implementation, presumably for
platforms where the standard inet_pton() isn't available, but it's not
exported in the public API.
My thought is to add a compile-time check if inet_pton() is available,
and otherwise steal APR's implementation. I don't like the code
duplication, but short of exposing APR's implementation (and then
waiting for it to be released), I don't see a third option.
If no-one has a better idea, I'll implement this in the next week or
so. It's the last missing part of the Unbound integration except for
the build configuration bits.
Apropos of all this, do we need an asynchronous version of
serf_listener_create() too? I'm not sure how this interacts with
HTTP/{2,3} support. For a "normal" server, I'd expect the synchronous
variant to be good enough.
Which reminds me that I noticed serf_listener_create() uses only the
first resolved address, so e.g., if we bind to "localhost" and that
resolves to both 127.0.0.1 and ::1, we'll use the first one returned by
the resolver and there's no way to tell which one that will be. That's
probably not as intended.
-- Brane
