John Hampton wrote:
So it simply tries to create an AF_INET socket from file descriptor 0.
I don't understand how this would work if fd 0 is tied to a UNIX
socket. However, it could be that it isn't. It could be that the
UNIX socket specified in the lighttpd config is actually used for
something else.
So, I got a response from the person who wrote the fcgi.py module. Here
is the explanation of why it works with AF_INET and AF_UNIX sockets:
{{{
Now that you've mentioned it, it does seem a bit odd. I had to do a bit
of digging in Python's C source and the C FCGI development kit to see
why this actually works. (I wrote the basis of the fcgi module many
years ago.)
You are correct, on UNIX-like systems, when the FCGI app is launched by
the webserver, file descriptor 0 will most likely be an AF_UNIX socket.
(But on Windows, it will be AF_INET...)
However, Python's socket.fromfd method assumes it is being passed a
valid socket descriptor, and it is. We just don't know what the family
type of the socket it is, and as far as I know, there's no real sane or
portable way to figure that out. So it is assumed to be AF_INET for
portability reasons.
The only time the family type is used (within the fcgi module) is the
.getpeername method call. Here, it is used to determine the initial size
of the sockaddr structure passed to the underlying getpeername syscall.
sizeof(sockaddr_in) will invariably be smaller than sizeof(sockaddr_un),
so in the case of AF_UNIX sockets, the retrieved peer name will most
likely be truncated.
This is fine, since the only thing that matters is whether or not the
call actually succeeds. It is used to test whether or not file
descriptor 0 is a socket or a standard file/pipe (as in the case when
the FCGI app is run as a normal CGI).
}}}
Hope that helps a little.
-John
_______________________________________________
Cherokee mailing list
[email protected]
http://www.0x50.org/cgi-bin/mailman/listinfo/cherokee
