Message6802

There are a few issues going on here.

First of all is bad reporting from the jython socket module. The option that is causing the error is not called "NI_IDN_USE_STD3_ASCII_RULES", but is actually "TCP_NODELAY". The problem here is that the two options share the same symbolic constant, 256. The reverse lookup process I used for improved error reporting is failing in this case. I need to correct that.

The second problem is that the CherryPy WSGI server is setting the TCP_NODELAY option on a listening socket. Strictly speaking, this option has no meaning for listening sockets, because it affects the way data is sent over the socket. But data is not sent over listening sockets, which are solely used for accepting incoming connections.

But many operating systems nowadays let the user set options on listening sockets: sockets which are accepted from the listening sockets then inherit these options. So if TCP_NODELAY is set on the listening socket, then all socket connections it accepts will inherit the TCP_NODELAY setting.

Jython currently does not support this socket option inheritance, but we have an open request to support socket option inheritance in this way.

Server sockets do not support client options and propagate them to 'accept'ed client sockets.
http://bugs.jython.org/issue1309

So you have two options in this case

1. Drop the use of the TCP_NODELAY socket option. In the CherryPy WSGI server, the "nodelay" option of the HTTPServer class determines this.

2. If you want to still use the TCP_NODELAY option on sockets connected to the client, then set the option directly on those sockets after they have been accept'ed.