Any source is broken once the domain name resolves to an IPv4 and IPv6 address but the provider binds to IPv4

[danielniccoli]

Original author: g...@openov.nl (October 11, 2011 23:52:26)

What steps will reproduce the problem?

1. Use a common source/backend scheme, lets take cherokee-admin
2. Notice that on some distribution binding to any, binds to a specific protocol family. For localhost IPv4.
3. Notice that the backend is bound to 127.0.0.1:4000
4. Notice that the latest Cherokee infrastructure should be able rotate over resolved addr_info.
5. Notice that while this should be the case, it is actually never rotating over a different address family, so in fact it should rotate over the entry, that fail: hence a connect that fails.
6. Notice that in this code all kind of other messy stuff doesn't work at all, and can (and will result in severe) badness.
7. Notice that the attached proposed 'fix' is in fact not a fix, because for each and every time a new source connects it will try the next entry in line, if this entry fails, it will actually restart an interpreter. So while rotating in in fact good, it can never maintain stability.
8. So the proposed changes show that some memory issues can be fixed.
9. The real solution is to actually lift the resolving part OUTSIDE source.c and inside source_interpreter.c (hence: virtualsources!)
10. Virtual sources can be disabled if they give a connection refused, like is the case with the Ubuntu/Debian users now trying to start the admin. But are ending up on [::1]:4000 instead of 127.0.0.1:4000.

What is the expected output? What do you see instead?
A working admin, or for that matter any source with two resolving addresses.

Original issue: http://code.google.com/p/cherokee/issues/detail?id=1281

[danielniccoli]

From ste...@konink.de on October 11, 2011 23:53:56
I really should set my Google Multi Domain sign in to another default address...

[danielniccoli]

From ste...@konink.de on October 13, 2011 16:53:56
skinkie@bdaeaea