[PATCH] standalone trac does not accept -b "::"

[sgala@…]

(error is: socket.gaierror: (-9, "Address family for hostname not supported")

The way sockets are initialized is wrong. trac (or the underlying wsgi code for python 2.4) is assuming socket.AF_INET before even knowing the server address.

Standard code for initializing a ipv6 aware socket, that will work in ipv4-only machines (see U. Drepper tutorial) is:

>>> import socket
>>> gais = socket.getaddrinfo("::",8000, socket.AF_UNSPEC, socket.SOCK_STREAM) # host, port, af, tcp, ... 
>>> for gai in gais:
...   try:
...     sock = socket.socket(*gai[:2])
...     sock.bind(gai[4])
...     break
...   except:
...     continue
... else:
...   sock = None
...   raise "Error, couldn't bind"

or something similar. This code should work on any python having getaddrinfo, which means anything modern enough. In fact this code will try to bind in any different possibilities given.

None means localhost in the most general way (127.0.0.1 or ::1); "::" or "0.0.0.0" means any ipv6/ipv4 or any ipv4 address. For concrete addresses, getaddrinfo will parse and take care of the socket parameters.

[anonymous]

someone should change this ticket to "tracd doesn't support IPv6" -b "::" doesn't ring a bell for most people… BTW this ticket is still valid for trac 0.11

[Christian Boos]

As we discussed r7915 on #irc, I came across this ticket and played around…

[Christian Boos]

When I start tracd with -b ::1 -p 8000, it seems I can successfully browser my Trac environment using ​http://[::1]:8000/devel

But then trying to connect ​http://127.0.0.1:8000/devel fails.

[Christian Boos]

attempts to listen on both ipv4 and ipv6 addresses

[Christian Boos]

​PythonBug:3213 and ​http://mail.python.org/pipermail/python-list/2008-May/489377.html were helpful here.

So with the second patch​ (which has to be applied in addition to the first), and starting tracd with -b :: -p 8000, I was able to connect to both ​http://[::1]:8000/devel and ​http://127.0.0.1:8000/devel (on Windows Vista).

As expected the second request shows up as a mapped ipv4 address:

::ffff:127.0.0.1 Trac[...

[Christian Boos]

Milestone 1.0 deleted

[Thijs Triemstra <lists@…>]

Seems to me this patch needs a review, I'll check it out.

[Thijs Triemstra <lists@…>]

#2491 is another ipv6 issue.