Passing the remote address to open_socket() would be semantically quite different from providing a local address if the only purpose is to get the adress family and not binding the socket.

I'm not quite sure I follow you. Of course it's different from providing a local address. So?

Anyway, those changes were the minimal needed to get

Protocols.HTTP.get_url("http://%5B::1%5D:1234/something/")

to succeed. Whether Query.pike could be redesigned was beyond the scope of my fix since I needed IPv6 functionality in place yesterday for a customer test.

But they are not sufficient to get

Protocols.HTTP.get_url("http://ipv6.google.com/something/")

to work.

I think it's very bad to commit ad-hoc hacks to the repository without prior discussion at this point in the release cycle. What you do in your working copy is your own business of course.

Though moving the DNS lookup in Query.pike::thread_request() ought to fix that since we'd check the IP instead of the host name.

Ok, true. So you'd want open_socket() to take extra parameters for the target machine's address and resolve that internally?

Well, the extra parameter is already there. But I'd rather see the target machine's address passed by user code than an integer computed by dubious means. open_socket() can then use get_inet_addr() to convert the string into an address family in exactly the same way that connect() would have done.

How did the people implementing v6 support in Pike 7.7 intend it to work?

My intention was that you should never have to worry about what protocol family an address uses. The protocol family numers are intentionally not exposed because a need to use them indicates a failure to achieve that goal, and a need to redesign some part of the API (in this case open_socket()).

Stdio.File::open_socket() doesn't have such a parameter that I can find. Which one are you referring to?

I'm referring of course to the "family" parameter (number 3 from the left).

My suggestion was for a union type, yes. connect() still needs to call it internally with the numeric argument (to prevent a double lookup). It should also have a new name, something like "target_hint".

If it wasn't for compatibility, I'd prefer removing open_socket() completely.

Yes, you can keep the object and reuse it. But in that scenario, you reuse con _after_ the connect(), not between the open_socket() and the connect(), so I don't think the call to open_socket() is necessary for this to work.