Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Originally reported by: Red_M (Bitbucket: Red_M, GitHub: Unknown)
I have found bug most likely caused by some bot on the internet as I get this every now and again.
The trace back:
This exception is not caught by the calls at line 909 or line 1378, it would be best to do so.
Hi Red. Thanks for linking your account.
Per the traceback, it seems that line 909 or 1378 are in wsgiserver2.
It's not obvious to my why it would be best to do so. What behavior are you expecting that you're not seeing? Why is suppressing the exception (at one of two places) a better solution? A patch may be useful to help illustrate what you have in mind.
Exception in thread CP Server Thread-141: Traceback (most recent call last): File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner self.run() File "/usr/local/lib/python2.7/dist-packages/cherrypy/wsgiserver/__init__.py", line 1583, in run conn.communicate() File "/usr/local/lib/python2.7/dist-packages/cherrypy/wsgiserver/__init__.py", line 1425, in communicate req.simple_response("408 Request Timeout") File "/usr/local/lib/python2.7/dist-packages/cherrypy/wsgiserver/__init__.py", line 899, in simple_response self.conn.wfile.write(EMPTY.join(buf)) File "/usr/local/lib/python2.7/dist-packages/cherrypy/wsgiserver/__init__.py", line 1046, in write bytes_sent = self.send(data) File "/usr/local/lib/python2.7/dist-packages/cherrypy/wsgiserver/ssl_pyopenssl.py", line 109, in send *args, **kwargs) File "/usr/local/lib/python2.7/dist-packages/cherrypy/wsgiserver/ssl_pyopenssl.py", line 91, in _safe_call raise wsgiserver.NoSSLError() NoSSLError
Line 1425 in
If the user is connecting to an SSL server but isn't doing SSL negotiation, I'm not sure there is a standard "this is HTTPS" response. I checked with Google's HTTPS server:
It didn't send anything, but instead just closed the connection.
I would expect CherryPy to do the same, and maybe that's what it does when the NoSSLError is raised. What's the unexpected behavior when this error is raised? It looks like that thread will crash. Is that a problem? Will CherryPy replace the thread?
Now that I look more closely at
At this point, I do think that both errors should be caught.
I was meaning stock standard for cherrypy, more so meaning canned response.
Talking to an SSL port on cherrypy when the client isn't talking SSL, would at one time with cherrypy, returned a response to the client similar to "This server talks HTTPS on this port but you are using HTTP"