WebSocket for CherryPy 3.2

Just a quick note about the first draft of support for WebSocket in CherryPy. You can find the code here.

Note that this is still work in progress but does work against Chrome and the pywebsocket echo client. It supports draft-76 of the specification only and I’m waiting for the working-group to settle a bit more before making any further modification.

The updated code has started integrating draft-06 as well but this is a work in progress.

11 thoughts on “WebSocket for CherryPy 3.2”

  1. The link for the code in this blog post is dead. Do you know what is the status of this project?


  2. I just updated the link. I’ve withdrawn my Trac instance as I wasn’t really using it anymore.

    The project is not dead but only supports draft-76 which is rather old now, I’ve been working on updating to the latest revision of the spec but didn’t complete the framing support yet.

  3. A few things I’ve noticed while trying to use your code…
    – There’s an instance of “handshakeError” that I think should be “HandshakeError”.
    – Lines 412 to 419 have bad indentation.
    – socket.fromfd isn’t available on Windows.

    And since I’m developing on Windows… that’s as far as I got.

    1. Hi Adam,

      Thanks for reporting where you’re at with the code.

      1. Right. Typos… :/
      2. Really? That’s strange. I will look at why this evening.
      3. Okay. The only reason i’m using fromfd() is because I want to avoid any trailing references to the CherryPy stack which holds the original socket. If I can find an alternative, I’ll be glad moving away from this call.

      As a side note, would it help if I moved the code to bitbucket so that you could fork and work on it more easily?

      1. I’m not really CherryPy-savvy enough to make many changes beyond what I pointed out, plus I’m not going to be using websockets in CherryPy for the time being, so… realistically I won’t be forking and coding any time soon.

        Sorry. It would still be awesome if it shows up in CherryPy, though. And I’ll ping you if it turns out I’m going to be looking at it again.

        1. Promising work, thanks!

          On the windows issue: the fromfd() issue has been discussed and (nearly) solved in http://bugs.python.org/issue1378 (for Python3). The final check ins have been http://hg.python.org/cpython/rev/70cfc7b504c2 and http://hg.python.org/cpython/rev/f6cca4b2260c (declaring the related dup support for ssl in windows more or less not implementable ;).

          There may have been plans to backport it to 2.6, as message http://bugs.python.org/issue1378#msg57494 says, but this probably (and unfortunately) has never happened.

          Perhaps, Sylvain finds an alternative solution.

  4. Hi Sylvain,

    As someone new to CherryPy I’ve tried to work with secure websockets using wss:// instead of ws://. Unfortunately, I have been unable to get the example you provided with your implementation to work. I modified the WebSocket call in the Javascript in the example (ws_server_draft76.py) to ask for a wss://, for example, but the server does not find any websocket hook to run.

    I’d appreciate any suggestions.

    I have another question, if you don’t mind: Would you suggest using your websocket extension with CherryPy in a production server at this point?

    Many thanks,
    === Huseyin

    1. Hi Huseyin,

      As for the issue you have met, it depends a bit on which version of the code you are using (most recent is at https://github.com/Lawouach/WebSocket-for-CherryPy). I must admit the code is in a rather miserable state right now as I’ve been pushing back finishing it. I have a clear weekend ahead of me so I’ll give it a try.

      Also the constant modification of the protocol were a drag but that seems to have improved.

      I wouldn’t recommend using the code in production at any rate. First of all because of the many issues and lack of proper and thorough testing but also because I don’t know how well that’d scale.

      1. Hi Sylvain,

        Thanks for your answer.

        It looks like I will have to resort to one of the “classic” methods for asynchronous communication rather than using websockets.

        BTW, I have the latest code you’d posted.

Comments are closed.