On 8/25/05, Joe Orton <[EMAIL PROTECTED]> wrote: > On Thu, Aug 25, 2005 at 09:09:18AM -0400, Jeff Trawick wrote: > > On 8/22/05, Jeff Trawick <[EMAIL PROTECTED]> wrote: > > Server is configured with --enable-v4-mapped (default on most > > systems), which is supposed to mean "just get one darn socket and > > handle both IPv4 and IPv6 traffic to that port on that socket". > > > > apr_sockaddr_info_get() is hard-coded (no control) to return a list of > > possible listening socket addresses when called from alloc_listener(). > > So we get IPv4 and IPv6 address back. > > Specifically what addresses, in what order? It looks like the logic in > open_listeners() which is supposed to cope with this stuff might fail if > you get AF_INET/0.0.0.0 followed by AF_INET6/[::] rather than the other > way round.
first entry: AF_INET; 0.0.0.0:8080 second (last) entry: AF_INET6; [::]:8080 But if it is the other way around: Get AF_INET6 socket first and set IPV6_V6ONLY to 0 (--enable-v4-mapped is the default on non *bsd). Then get AF_INET socket and try to bind. Why is that guaranteed to work since we have overlap? Even if it works on common systems, it negates --enable-v4-mapped. Seems to me that we should scrap the --enable-v4-mapped stuff, default to getting two listening sockets everywhere (if IPv6 enabled, of course), and (future) have a Listen option to get a single socket to handle mapped addresses. With that Listen option we'd just pass AF_INET6 instead of AF_UNSPEC on the resolver call since the admin who specified that option knows what they're doing. (Why bother with mapped addresses? go a little faster, avoid common accept-mutex-related snafus, provide easy way to test single-socket path)
