CherryPy is a pythonic, object-oriented HTTP framework. https://docs.cherrypy.org/

On Debian 9, with OpenSSL 1.1.0f 25 May 2017 CherryPy will thrown this (non-fatal) error on startup when using the 'server.ssl_module': 'builtin'. It does not happen when using 'server.ssl_module': 'pyopenssl'.

This is not just on our older CherryPy, but also on the latest CherryPy version 11 and both on Python 2.7 and Python 3.5.

We have been chasing this error for a while and first assumed it was a bug in Python. I was ready to report it to Python bug-tracker, but I cannot reproduce it using pure-python. So it really is something specific to what CherryPy does.

Code:

import cherrypy
print(cherrypy.__version__)

class RootServer:
    @cherrypy.expose
    def index(self, **keywords):
        return "it works!"

if __name__ == '__main__':
    server_config={
        'server.socket_host': '0.0.0.0',
        'server.socket_port': 9090,
        'server.ssl_module': 'builtin',
        #'server.ssl_module':'pyopenssl',
        'server.ssl_certificate':'/root/.sabnzbd/admin/server.cert',
        'server.ssl_private_key':'/root/.sabnzbd/admin/server.key'
    }

    cherrypy.config.update(server_config)
    cherrypy.quickstart(RootServer())

Error thrown by Python 2.7 and 3.5:

11.0.0
[11/Aug/2017:13:23:57] ENGINE Listening for SIGHUP.
[11/Aug/2017:13:23:57] ENGINE Listening for SIGTERM.
[11/Aug/2017:13:23:57] ENGINE Listening for SIGUSR1.
[11/Aug/2017:13:23:57] ENGINE Bus STARTING
CherryPy Checker:
The Application mounted at '' has an empty config.

[11/Aug/2017:13:23:57] ENGINE Started monitor thread '_TimeoutMonitor'.
[11/Aug/2017:13:23:57] ENGINE Started monitor thread 'Autoreloader'.
[11/Aug/2017:13:23:57] ENGINE Serving on https://0.0.0.0:9090
[11/Aug/2017:13:23:57] ENGINE Bus STARTED
[11/Aug/2017:13:23:57] ENGINE Error in HTTPServer.tick
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/cheroot/server.py", line 1515, in start
    self.tick()
  File "/usr/local/lib/python2.7/dist-packages/cheroot/server.py", line 1590, in tick
    s, ssl_env = self.ssl_adapter.wrap(s)
  File "/usr/local/lib/python2.7/dist-packages/cheroot/ssl/builtin.py", line 73, in wrap
    server_side=True)
  File "/usr/lib/python2.7/ssl.py", line 363, in wrap_socket
    _context=self)
  File "/usr/lib/python2.7/ssl.py", line 611, in __init__
    self.do_handshake()
  File "/usr/lib/python2.7/ssl.py", line 840, in do_handshake
    self._sslobj.do_handshake()
error: [Errno 0] Error

Pure-python code version trying to reproduce all steps cherrypy performs, that does not thrown the error:

import socket, ssl
import fcntl

print "Start"
context = ssl.create_default_context(ssl.Purpose.CLIENT_AUTH)
context.load_cert_chain(certfile="/root/.sabnzbd/admin/server.cert", keyfile="/root/.sabnzbd/admin/server.key")

bindsocket = socket.socket()
bindsocket.bind(('0.0.0.0', 9090))
bindsocket.listen(5)

while True:
    newsocket, fromaddr = bindsocket.accept()

    fd = newsocket.fileno()
    old_flags = fcntl.fcntl(fd, fcntl.F_GETFD)
    fcntl.fcntl(fd, fcntl.F_SETFD, old_flags | fcntl.FD_CLOEXEC)

    sslsoc = context.wrap_socket(newsocket, do_handshake_on_connect=True, server_side=True)
    request = sslsoc.read()
    print(request)
    print(sslsoc.cipher())
print "Done"

@sanderjo also created a guide to setting-up a docker to with Debian to test this: https://github.com/sabnzbd/sabnzbd/issues/1000 For non-docker-people like me, this command can be used to copy files into the docker:

sudo docker cp test.py DOCKER-ID:/test.py

Originally reported by: Tim Miller (Bitbucket: lashni, GitHub: Unknown)

http://docs.cherrypy.org/en/latest/advanced.html#no-need-for-the-wsgi-interface

Error is encountered when the example code from the link above is run under a python 3.4.3 virtualenv on archlinux, traceback triggers when the server is accessed. Error doesn't occur with python 2.7.10.

Happens with both current head and CherryPy 3.8.0.

[19/Jul/2015:17:41:01] ENGINE Listening for SIGUSR1.
[19/Jul/2015:17:41:01] ENGINE Listening for SIGTERM.
[19/Jul/2015:17:41:01] ENGINE Listening for SIGHUP.
[19/Jul/2015:17:41:01] ENGINE Bus STARTING
CherryPy Checker:
The Application mounted at '' has an empty config.

[19/Jul/2015:17:41:01] ENGINE Started monitor thread '_TimeoutMonitor'.
[19/Jul/2015:17:41:01] ENGINE Started monitor thread 'Autoreloader'.
[19/Jul/2015:17:41:01] ENGINE Serving on http://127.0.0.1:8080
[19/Jul/2015:17:41:01] ENGINE Bus STARTED
[19/Jul/2015:17:41:05] NATIVE_ADAPTER Traceback (most recent call last):
  File "/home/lashni/dev/serve/lib/python3.4/site-packages/cherrypy/_cpnative_server.py", line 27, in respond
    sn = cherrypy.tree.script_name(req.uri or "/")
  File "/home/lashni/dev/serve/lib/python3.4/site-packages/cherrypy/_cptree.py", line 257, in script_name
    path = path[:path.rfind("/")]
TypeError: 'str' does not support the buffer interface

ValueError('invalid literal for int() with base 10: "b\'5"',)
Traceback (most recent call last):
  File "/home/lashni/dev/serve/lib/python3.4/site-packages/cherrypy/_cpnative_server.py", line 27, in respond
    sn = cherrypy.tree.script_name(req.uri or "/")
  File "/home/lashni/dev/serve/lib/python3.4/site-packages/cherrypy/_cptree.py", line 257, in script_name
    path = path[:path.rfind("/")]
TypeError: 'str' does not support the buffer interface

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/lashni/dev/serve/lib/python3.4/site-packages/cherrypy/wsgiserver/wsgiserver3.py", line 1068, in communicate
    req.respond()
  File "/home/lashni/dev/serve/lib/python3.4/site-packages/cherrypy/wsgiserver/wsgiserver3.py", line 856, in respond
    self.server.gateway(self).respond()
  File "/home/lashni/dev/serve/lib/python3.4/site-packages/cherrypy/_cpnative_server.py", line 88, in respond
    self.send_response(s, h, b)
  File "/home/lashni/dev/serve/lib/python3.4/site-packages/cherrypy/_cpnative_server.py", line 101, in send_response
    req.send_headers()
  File "/home/lashni/dev/serve/lib/python3.4/site-packages/cherrypy/wsgiserver/wsgiserver3.py", line 912, in send_headers
    status = int(self.status[:3])
ValueError: invalid literal for int() with base 10: "b'5"

• Bitbucket: https://bitbucket.org/cherrypy/cherrypy/issue/1377

Originally reported by: Jason R. Coombs (Bitbucket: jaraco, GitHub: jaraco)

In order to be more visible and friendly to more contributors, CherryPy should consider moving to Github.

Github is the canonical and preferred hosting for most open source projects.

I'm willing to help with the process, but I first want to get the nod from @cyraxjoe and @Lawouach. Also, we'll need to create a CherryPy org (if there's not a better one to host it).

I propose migrating the existing issues to Github using https://github.com/jeffwidman/bitbucket-issue-migration or one of its many forks. I'm happy to test and execute that.

• Bitbucket: https://bitbucket.org/cherrypy/cherrypy/issue/1410

Originally reported by: guest (Bitbucket: guest, GitHub: guest)

There is a big problem with CP in conjunction with Python 2.4.4 on Tiger!

Did you ever try to respond an image (1 Mpx) directly by cherrypy?

I installed Python 2.4.4 Universal Binary Installer, then CherryPy 2.2.1 on Mac OS X Tiger 10.4.8 (Mac Mini Dual Core 2).

My CherryPy App should deliver images (jub -- dynamicly generates ones), but I always receive only the first part of the image in my browser. Cherrypy throws an exception within the write-method, which is delegated to socket-write which ends up in a sendall in socket.py:

error 35: Resource temporarily unavailable.

Seams that this is a problem caused by some changes in the socket api between Python 2.4.3 and 2.4.4. If this is true and I didn't make a mistake, CherryPy can not be used upon P 2.4.4 on Tiger (if you try to respond something bigger than a small HTML page).

I am thinking on Kevin Dangoors nice Turbogears Screencast, running on Max OS X... How should people redo this cool stuff he shows...?

• Bitbucket: https://bitbucket.org/cherrypy/cherrypy/issue/598

Originally reported by: cdent (Bitbucket: cdent, GitHub: cdent)

When installing CherryPy with modern pip, wsgiserver2.py is missing. Upon investigation I discovered (by download both by hand) that the .whl file doesn't have it, but the .tar.gz file does.

The ssl_pyopenssl.py from the same directory also appears to be missing from the wheel file.

Forcing pip to --no-use-wheel gets the desired results, but clearly there's some kind of packaging error going on?

• Bitbucket: https://bitbucket.org/cherrypy/cherrypy/issue/1295

Originally reported by: Anonymous

Using a recent checkout of CherryPy 3.2.5 and a recent nightly build of PyPy, SSL support doesn't seem to work.

I have tried pyOpenSSL 0.12 (pypy version), pyOpenSSL 0.14, and CherryPy "builtin". In all cases, CherryPy starts up and runs fine, throws no errors, but I can't connect via HTTPS.

In production I'm using an older (circa 9 months) nightly build of PyPy, CherryPy 3.2.4 and pyOpenSSL 0.12 and it works fine.

My connection code:

#!python

server2 = cherrypy._cpserver.Server()
            server2.socket_port = 443
            server2.socket_host = LISTEN_HOST
            server2.thread_pool = 30
            server2.ssl_module = 'pyopenssl'
            server2.ssl_certificate = SSL_CERTIFICATE_PATH
            server2.ssl_private_key = SSL_KEY_PATH
            server2.subscribe()

• Bitbucket: https://bitbucket.org/cherrypy/cherrypy/issue/1298

Originally reported by: Anonymous

Enhancement

Adding support for client SSL certificate verification to wsgiserver's SSLAdapter

Reason

SSL support is critical for modern webservers to provide secure services to users. However, there are times when applications running behind the webservers need to determine which clients are actually communicating them. While HTTP basic_auth can provide authentication, SSL provides another means to verify client identity: client certification verification.

Similar to the server providing its SSL certificate, when client verification is in use, clients must provide a certificate signed by a CA that the server recognizes in order for the client to be allowed to connect.

Changes

This patch adds another optional keyword argument to the SSLAdapter __init__() called ''client_CA''. ''client_CA'' is a string that contains a path to a CA certificate. When client_CA is present, the SSLAdapter knows to perform client verification using this CA. When absent, SSLAdapter behaves as before, ie with no client verification.

Bugs/Issues

While verification is performed correctly for both the ssl_pyopenssl SSLAdapter and the ssl_builtin SSLAdapter, the different implementations provide varying levels of support for SSL client environment variables that are traditionally provided by Apache's mod_ssl. See this page for details Mod_SSL Environment Variables.

ssl_pyopenssl currently provides '''no''' client environment variables due to the fact that the SSL handshake and thus the access to the client's certificate occurs at first data transfer - well after the environment variables are set by the SSLAdapter wrap() function.

ssl_builtin provides minimal environment variables. The major limiting factor is that python's builtin ssl routines only expose a small amount of information about the certificates, and then only for the client certificate. This problem will be difficult to fix if ssl_builtin must depend solely on python's ssl.

Patch

See attached Diff

Reported by [email protected]

• Bitbucket: https://bitbucket.org/cherrypy/cherrypy/issue/1001

@webknjaz has proposed Cherrypy.org be hosted through a free CloudFlare account to give a better experience and host the site under SSL. To accomplish this, there are a few steps.

• [x] Create a CloudFlare account with some shared management.
• [x] Import the domain records as currently hosted with WebFaction to CloudFlare.
• [x] Reconfigure the cherrypy.org domain at the registrar to CloudFlare.

It's important that the CloudFlare account be under shared management such that more than one maintainer has the ability to manage the domain.

Originally reported by: Fred Rupert (Bitbucket: fred_rupert, GitHub: Unknown)

CherryPy is leaving hundreds of close_wait connections open, I have to restart my CherryPy server every couple of days because it doesn't allow any more connections, and when I check netstat I see hundreds of close_wait connections.

I know this has been brought up a number of times here, does anyone know if a definitive cause has been found for it, or if there is a fix/work around for it?

TIA

• Bitbucket: https://bitbucket.org/cherrypy/cherrypy/issue/1304

• Windows 8.1 64bit
• Python 2.7.15 32bit
• py2exe 0.6.10a1
• CherryPy 16.0.2
• Cheroot 6.3.2.post0
• tempora 1.13
• jaraco.functools 1.20

"ImportError: No module named jaraco.functools" raised in my app frozen by py2exe.

D:\prj\test\dist_py2exe>test.exe
----------------------------------------
main : Unhandled error
Traceback (most recent call last):
...
  File "cherrypy\process\servers.pyo", line 126, in <module>
  File "zipextimporter.pyo", line 74, in load_module
  File "portend.pyo", line 18, in <module>
  File "zipextimporter.pyo", line 74, in load_module
  File "tempora\timing.pyo", line 12, in <module>
ImportError: No module named jaraco.functools

jaraco.functools seems the namespace package. This issue may be same to https://github.com/jaraco/jaraco.classes/issues/3

Is allowed the namespace package in CherryPy? https://github.com/cherrypy/cherrypy/issues/1673

AntiStampede Cache leaves orphaned threading.Event object on 304 Not Modified response and results in a 30 second timeout on subsequent request.

We are not able to reliably reproduce this problem, we only know that it happens and have the logs to scrutinize the TOOLS.CACHING code path followed when hitting the bug.

We've narrowed down the bug to

• static files
• an 'If-Modified-Since' request provoking a 304 Not modified response, leaving an orphaned threading.Event, causing
• a 30 seconds timeout on subsequent (normal) request

The logs show that the 304 provoking request follows the AntistampeCache.wait path, setting the threading.Event while returning a None to MemoryCache.get() variant object, causing it to return None to get()'s cache_data, causing it to follow the 'request is not cached' path of get(), returning False, but MemoryCache.put() is never called, thus leaving the threading.Event object orphaned.

The subsequent request for the same static file also follows the AntistampeCache.wait path. Encountering the orphaned threading.Event object causing it to fruitlessly wait 30 seconds after which it resolves the problem by diligently populating the cache object with the (eventually) responded static file.

After this, normal operation is resumed.

This happens mostly once a day, probably after cache has expired, after one of the clients was the last to requests an 'If-Modified-Since' static file response. But until now, we were not able to come up with a clean reproducible test case.

CherryPy is part of the Pyff daemon we deployed. https://github.com/leifj/pyFF/issues/116

• CherryPy version: 11.1.0
• Python version: 2.7 due to Pyff dependancy
• OS: Debian GNU/Linux 9
• Browser: Chrome 63

The logging showing the problem, which was produced by us inserted extra debugging lines looks as follows. I understand that interpreting these logs without knowledge of the location of these statements is awkward. Nevertheless it clearly shows the timeout after the offending 304'd static file request.

Jan 19 08:43:26 proxy2 pyffd[4100]: [19/Jan/2018:08:43:26] TOOLS.CACHING get https:/***/static/bootstrap/css/bootstrap.min.css
Jan 19 08:43:26 proxy2 pyffd[4100]: [19/Jan/2018:08:43:26] TOOLS.CACHING Wait result for key: (), type(value) <type 'NoneType'>
Jan 19 08:43:26 proxy2 pyffd[4100]: [19/Jan/2018:08:43:26] TOOLS.CACHING Cache was None, set Event <threading._Event object at 0x7f7b6c623a50>
Jan 19 08:43:26 proxy2 pyffd[4100]: [19/Jan/2018:08:43:26] TOOLS.CACHING variant found
Jan 19 08:43:26 proxy2 pyffd[4100]: [19/Jan/2018:08:43:26] TOOLS.CACHING request is not cached
[...]
Jan 19 08:43:26 proxy2 pyffd[4100]: 145.97.144.156 - - [19/Jan/2018:08:43:26] "GET /static/bootstrap/css/bootstrap.min.css HTTP/1.1" 304 - "https://***/role/idp.ds?return=https%3A%2F%2F***%2FSaml2SP%2Fdisco&entit
yID=https%3A%2F%2F***%2FSaml2SP%2Fproxy_saml2_backend.xml" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"


Jan 19 08:47:52 proxy2 pyffd[4100]: [19/Jan/2018:08:47:52] TOOLS.CACHING get https://***/static/bootstrap/css/bootstrap.min.css
Jan 19 08:47:52 proxy2 pyffd[4100]: [19/Jan/2018:08:47:52] TOOLS.CACHING Wait result for key: (), type(value) <class 'threading._Event'>
Jan 19 08:47:52 proxy2 pyffd[4100]: [19/Jan/2018:08:47:52] TOOLS.CACHING Event <threading._Event object at 0x7f7b6c623a50>
Jan 19 08:47:52 proxy2 pyffd[4100]: [19/Jan/2018:08:47:52] TOOLS.CACHING Waiting up to 30 seconds
[...]
Jan 19 08:48:22 proxy2 pyffd[4100]: [19/Jan/2018:08:48:22] TOOLS.CACHING Timed out 30 seconds
Jan 19 08:48:22 proxy2 pyffd[4100]: [19/Jan/2018:08:48:22] TOOLS.CACHING variant found
Jan 19 08:48:22 proxy2 pyffd[4100]: [19/Jan/2018:08:48:22] TOOLS.CACHING request is not cached
Jan 19 08:48:22 proxy2 pyffd[4100]: [19/Jan/2018:08:48:22] TOOLS.CACHING get() status: None
Jan 19 08:48:22 proxy2 pyffd[4100]: [19/Jan/2018:08:48:22] TOOLS.CACHING Storing status: 200 OK, uri:https://***/static/bootstrap/css/bootstrap.min.css
Jan 19 08:48:22 proxy2 pyffd[4100]: 2001:610:514:172:31da:c3b9:12ad:1b76 - - [19/Jan/2018:08:48:22] "GET /static/bootstrap/css/bootstrap.min.css HTTP/1.1" 200 109518 "https://***/role/idp.ds?return=https%3A%2F%2F***%2FSaml2SP%2Fdisco&entityID=https%3A%2F%2F***%2FSaml2SP%2Fproxy_saml2_backend.xml" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36"

What we noticed is that the caching.py get() cherrypy.HTTPRedirect 304 exception code path is not touched on the 304 response. This must mean that the 304 is generated in static.py in serve_file() by cptools.validate_since().

Up to now, we were unable to explain why this specific 304 response would provoke the cacheobject not to be populated by the corresponding cache, while having set a threading.Event.

What we did see was that MemoryCache.expire_cache() clears (del) the AntistampedeCache variant object in the store dictionary, but keeps the store uri key. This means that after cache expiration a store[uri] key exists but has no cache object attached. This might explain the 304 following the Antistampede.wait path without replacing the threading.Event object but we were not sure and unable to force faster cache expiration to produce a test-case (up to now).

For now, we had to decide to let the bug go and work-around it by letting nginx serve Pyff's static files, although this is a less than ideal solution of course.

I'm submitting a ...

• [ ] bug report
• [x] feature request
• [ ] question about the decisions made in the repository

Do you want to request a feature or report a bug?

What is the current behavior?

If the current behavior is a bug, please provide the steps to reproduce and if possible a screenshots and logs of the problem. If you can, show us your code.

What is the expected behavior?

What is the motivation / use case for changing the behavior?

Please tell us about your environment:

• Cheroot version: X.X.X
• CherryPy version: X.X.X
• Python version: 3.6.X
• OS: XXX
• Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, e.g. stackoverflow, gitter, etc.)

python-memcached is not maintained, this patch replaces the usage of python-memcached with the pymemcache python package.

Fix https://github.com/cherrypy/cherrypy/issues/1983

What kind of change does this PR introduce?

• [ ] bug fix
• [ ] feature
• [ ] docs update
• [ ] tests/coverage improvement
• [ ] refactoring
• [x] other

What is the related issue number (starting with #)

#1983 1983

What is the current behavior? (You can also link to an open issue here)

Depends on python-memcached

What is the new behavior (if this is a feature change)?

Depends on pymemcache

Checklist:

• [x] I think the code is well written
• [x] I wrote good commit messages
• [x] I have squashed related commits together after the changes have been approved
• [x] Unit tests for the changes exist
• [x] Integration tests for the changes exist (if applicable)
• [x] I used the same coding conventions as the rest of the project
• [x] The new code doesn't generate linter offenses
• [x] Documentation reflects the changes
• [x] The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences

I'm submitting a ...

• [ ] bug report
• [x] feature request
• [ ] question about the decisions made in the repository

Do you want to request a feature or report a bug?

It's a maintenance request. The package python-memcached is not actively maintained anymore and other package could be a better option to depend on, for example https://github.com/pinterest/pymemcache

I'm submitting a ...

• [ ] bug report
• [ ] feature request
• [x] question about the decisions made in the repository

Do you want to request a feature or report a bug?

Neither

What is the current behavior?

When i was packaging cherrypy in fedora copr, i met a license issue, seems the License :: Freely Distributable is not compatible in fedora community.

Assuming PyPI --version=18.8.0
Attempting to get license from Classifiers
License 'Freely Distributable' is or may not be allowed in Fedora, quitting
stderr: 

FYI, https://github.com/befeleme/pyp2spec/issues/29

If the current behavior is a bug, please provide the steps to reproduce and if possible a screenshots and logs of the problem. If you can, show us your code.

NA

What is the expected behavior?

Since cherrypy is mainly licensed under BSD, it should be packaged in fedora community. What‘s the backgroup of classifier License :: Freely Distributable in setup.py? The fedora team's advices are acceptable?(remove the License :: Freely Distributable entry)

What is the motivation / use case for changing the behavior?

We want to import cherrypy to feodra for some other software use it.

Please tell us about your environment: NA

Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, e.g. stackoverflow, gitter, etc.)

Hi cherrypy/cherrypy!

This is a one-off automatically generated pull request from LGTM.com :robot:. You might have heard that we’ve integrated LGTM’s underlying CodeQL analysis engine natively into GitHub. The result is GitHub code scanning!

With LGTM fully integrated into code scanning, we are focused on improving CodeQL within the native GitHub code scanning experience. In order to take advantage of current and future improvements to our analysis capabilities, we suggest you enable code scanning on your repository. Please take a look at our blog post for more information.

This pull request enables code scanning by adding an auto-generated codeql.yml workflow file for GitHub Actions to your repository — take a look! We tested it before opening this pull request, so all should be working :heavy_check_mark:. In fact, you might already have seen some alerts appear on this pull request!

Where needed and if possible, we’ve adjusted the configuration to the needs of your particular repository. But of course, you should feel free to tweak it further! Check this page for detailed documentation.

Questions? Check out the FAQ below!

FAQ