Server: FreeBSD 6.0, Python 2.4.2, CP 2.1
Client: WinXP SP1, Firefox 1.07
I'm seeing a consistent hang in CherryPy when a client issues a TCP reset. The easiest way to repro it:
On the server:
1. tg-admin quickstart resettest
2. cd resettest && python resettest-start.py
On the client:
1. Go to http://servermachine:8080/
2. After it loads, pound on the "reload page" button quickly.
After about 5 or 6 refreshes, the server gets a traceback:
192.168.1.254 - - [2005/11/04 16:41:16] "GET / HTTP/1.1" 200 2101
Exception in thread Thread-3:
Traceback (most recent call last):
File "/usr/local/lib/python2.4/threading.py", line 442, in __bootstrap
self.run()
File "/usr/local/lib/python2.4/site-packages/CherryPy-2.1.0-py2.4.egg/cherrypy/_cpwsgiserver.py", line 247, in run
request.write(line)
File "/usr/local/lib/python2.4/site-packages/CherryPy-2.1.0-py2.4.egg/cherrypy/_cpwsgiserver.py", line 192, in write
self.wfile.flush()
File "/usr/local/lib/python2.4/socket.py", line 243, in flush
self._sock.sendall(buffer)
error: (54, 'Connection reset by peer')
At this point, the whole server process is hung (doesn't accept new
connections), and won't die until I kill it. I've checked with a
packet sniffer, and I can see that when the server is delivering page
information after the user has reloaded the page, the browser sends a
TCP RST, and nothing in the server's call frame is handling it.
Makes for a fine denial of service attack...
It looks like a straightforward CherryPy bug, but before I file it
there, can anyone try reproducing this in another environment? Note
that it doesn't reproduce when the client and server are on the same
machine--no chance for a TCP reset over loopback, I imagine.
Thanks much!
--
Tim Lesher <[EMAIL PROTECTED]>
- [TurboGears] Consistent CherryPy hang on TCP reset Tim Lesher
