`'SSL_PROTOCOL': cipher[1]` => "TypeError: 'NoneType' object is not subscriptable"

[evandrix]

trafficstars

Anyone encountered this error message before?

I've been running a CherryPy server in production, and it seemed to have "hanged" i.e. server process still running, but requests are not being serviced, the following being the last error message captured:

Edit: I have since updated to the latest at the point of writing i.e. cheroot-8.5.2, waiting to see if this happens again

• Ubuntu 20.04.2 LTS
• Python 3.8.5
• cheroot-8.4.5

Error in HTTPServer.tick
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/dist-packages/cheroot/server.py", line 1798, in serve
    self.tick()
  File "/usr/local/lib/python3.8/dist-packages/cheroot/server.py", line 2038, in tick
    conn = self._connections.get_conn()
  File "/usr/local/lib/python3.8/dist-packages/cheroot/connections.py", line 163, in get_conn
    return self._from_server_socket(self.server.socket)
  File "/usr/local/lib/python3.8/dist-packages/cheroot/connections.py", line 190, in _from_server_socket
    s, ssl_env = self.server.ssl_adapter.wrap(s)
  File "/usr/local/lib/python3.8/dist-packages/cheroot/ssl/builtin.py", line 329, in wrap
    return s, self.get_environ(s)
  File "/usr/local/lib/python3.8/dist-packages/cheroot/ssl/builtin.py", line 337, in get_environ
    'SSL_PROTOCOL': cipher[1],
TypeError: 'NoneType' object is not subscriptable

[webknjaz]

Anyone encountered this error message before?

No.

Please fill out the form when reporting issues. This doesn't look actionable. No reproducer or conditions. That said, there's no way of guessing what you did, how you deployed or used it, or if there's any real-world scenario of triggering this behavior.

The docs say that SSLSocket.cipher() returns None in case if there's no connection established. So you'll have to maybe record network traffic to track down what's happening. I think maybe a disconnect happens between the connection is established and SSLSocket.cipher() is called. OTOH there's been a number of bugfixes since v8.4.5.

One case that comes to my mind: can it be that because we reuse connections, when we use a connection for the second time the underlying TCP connection may have timed out?

cc @the-allanc @liamstask @mxii-ca

[jreremy]

I'm running into the same issue using cheroot with bottle:

• cheroot-8.5.2
• Ubuntu 20.04.1 LTS
• python 3.8.5

The following is my deployment. Haven't been able to reproduce it reliably, sometimes the error occurs days/weeks after starting the server, and sometimes the server runs for extended periods of time without issue.

from bottle import ServerAdapter, run
class SSLCherootAdapter(ServerAdapter):
    def run(self, handler):
        from cheroot import wsgi
        from cheroot.ssl.builtin import BuiltinSSLAdapter
        import ssl

        server = wsgi.Server((self.host, self.port), handler)
        server.ssl_adapter = BuiltinSSLAdapter("cacert.pem", "privkey.pem")

        # By default, the server will allow negotiations with extremely old protocols
        # that are susceptible to attacks, so we only allow TLSv1.2
        server.ssl_adapter.context.options |= ssl.OP_NO_TLSv1
        server.ssl_adapter.context.options |= ssl.OP_NO_TLSv1_1

        try:
            server.start()
        finally:
            server.stop()

run(host='localhost', port=8080, server=SSLCherootAdapter)

[webknjaz]

@jreremy we need a Cheroot-only reproducer because third-party wrappers may change some behavior and nobody has resources to debug that.

[neighbour-oldhuang]

I'm in same trouble， 我遇到了同样的问题，是在saltstack 的 salt-api 中出现的，报错信息跟楼主一样，而且是周期性的每隔几秒出现，但是api仍然可以正常提供服务