Jason R. Coombs

When I run the tests with `-s`, I see this traceback before things hang: ``` Exception in thread Thread-44: Traceback (most recent call last): File "/usr/local/Cellar/python@2/2.7.16/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 801, in __bootstrap_inner...

It looks to me like it does rely on (a subclass of) `io.BufferedWriter` (`StreamWriter -> BufferedWriter -> io.BuferedWriter'). I don't see that property present on my BufferedWriter either on Python...

I believe it's a design intention that `cherrypy.engine` be a convenient global variable that represents the one and only engine that most users will use. Therefore, the expectation you report...

Under what conditions does this occur? Could it be that the remote end has just stopped receiving data? Maybe someone's cell phone went into a train tunnel. Maybe the user...

There are almost certainly users relying on this existing behavior, so it probably demands a backward-incompatible release. @Safihre, I'd be happy to accept a PR with the above change if...

I've distilled your repo to [this script](https://gist.github.com/d654d01eeeb64a1758eb0a60661e5bbf), which will run the server and test it with a few requests before exiting. It's configured to run with all the dependencies using...

git bisect is an absolute dream. [Using that script, I bisected the codebase](https://gist.github.com/d20730c0ecbcc49f3e4df4645096c13c). It implicated c87bc9f73740dfe35e4d2ca9082dccb6278bdc53.

@webknjaz In your replication attempt, you’re not passing the query params. The 404 only occurs if there are query params present.

This is one of the intermittent test failures we're [seeing more frequently in Travis](https://travis-ci.org/cherrypy/cherrypy/jobs/186430884) after switching to pytest.

It does seem this issue has increased dramatically, like from 5% to 95% between 17.x and 18.x. I'm going to bisect and find the cause.