I seem to remember seeing this in Django too, but I could be wrong (might have been Quixote or Myghty).
That probably does not help, though. :-( Krys Tim Lesher wrote: > 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 <http://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]> >
