WebSockets and HTTP sharing the same port using request headers

[pshaughn]

RFC 6455 doesn't mandate that a WebSocket server implementation be able to share the same port with HTTP, but the protocol was designed to allow the possibility.

Currently, WebSocketServerProtocol.handshake doesn't test for the "Upgrade: websocket" header. This doesn't cause any problems because only a WebSocket client would be able to finish the handshake process, but it does appear to rule out port sharing.

It would be convenient in some cases to be able to pass something like an HTTPServer into the WebSocketServer constructor and have requests without the "Upgrade: websocket" header be forwarded to it.

I realize that just putting WebSocket traffic on its own port solves the same problem more easily in most cases, so this idea probably isn't worth implementing if it would take a lot of effort.

[aaugustin]

Indeed, I didn't want to implement a HTTP server, only a websocket server (unlike e.g. aiohttp).

You can /probably/ inherit or wrap WebSocketServerProtocol into something that handles HTTP. I made an effort in the design of the API not to rule out this possibility immediately, but I never tried it, so it's entirely possible that it doesn't work...

If you try it, I'm interested into hearing about the results :-) However I suspect it will always be easier to run on a different IP or port.

[ghostplant]

I also need this feature, because it will make deployment more easy when been packaged by docker and other engines. Sharing the same port will make it easy to design the port forwarding : )

[ghostplant]

I just implement web ssh (https://github.com/ghostplant/websocket-myssh-tunnel.git) using this websockets library, but listening on two ports (8022/8023) seems to be ugly. I am finding a solution.

I think supporting static html files based on GET method (like a SimpleHTTPServer do) will be enough because javascript in html will be able to communicate with the websocket server!

[aaugustin]

I believe the Docker best practice is to run different services in different containers, so you shouldn't serve static contents and websockets from the same container?

Supporting static file isn't enough, someone will ask for dynamic stuff shortly thereafter...

[pshaughn]

In your case, ghostplant, it sounds like you can use a regular web-server with server-side proxying, and have it proxy requests on a specific path into the websocket port. Since you're already using Docker, you can easily set up nginx to do that.

[ghostplant]

Firstly, Python Flask / Java Tomcat based websocket are designed to share http port and websocket port.

Secondly, if I seperate them two into different docker, when it comes to deploy multiple group of these services, it will be a little more complex, because javascript (from html client side) has to write a complex proceduce to calculate the corrent port of proxy requests to the websocket server.

[ghostplant]

To some extent, HTTP Request and WebSocket Request have same format so they can be regarded as one service.

[pshaughn]

I like that this is just a pure-Python websockets program with no framework dependencies, and I wouldn't want that to change. For your port-combining case, ghostplant, you can put nginx and this in the same Docker container, expose just the nginx port of that container, and set up nginx as a reverse proxy forwarding one path to the non-exposed websocket port and serving the other path itself, thus getting a container with one visible port serving both websocket and http requests.

[aaugustin]

I have to say that I don't aim at competing with Tomcat ;-) More seriously, websockets isn't designed to support HTTP(S). The scope of this issue is to make it easier to integrate with a third-party server.

[ghostplant]

So can you add a hook to allow users to implement handling HTTP event by themselves? Current "handshake" method in server.py doesn't satisfy idempotency so if users inherit that Protocol, they have to re-implement most of the codes.

I suggest two ways to support this hook in server.py, approximately adding 2-8 lines. Can I suggest the PR?

[aaugustin]

Of course you can submit a PR, that's the best way to describe the approach you're proposing.

[tgwizard]

I hacked together a simple subclass of WebSocketServerProtocol that can also serve regular HTTP requests. Something like this:

class HttpWSSProtocol(websockets.WebSocketServerProtocol):
    async def handler(self):
        try:
            request_line, headers = await websockets.http.read_message(self.reader)
            method, path, version = request_line[:-2].decode().split(None, 2)
        except:
            self.writer.close()
            self.ws_server.unregister(self)
            raise

        # TODO: Check headers etc. to see if we are to upgrade to WS.
        if path == '/ws':
            # HACK: Put the read data back, to continue with normal WS handling.
            self.reader.feed_data(bytes(request_line))
            self.reader.feed_data(headers.as_bytes().replace(b'\n', b'\r\n'))
            return await super(HttpWSSProtocol, self).handler()
        else:
            try:
                return self.http_handler(method, path, version)
            finally:
                self.writer.close()
                self.ws_server.unregister(self)

    def http_handler(self, method, path, version):
        response = '\r\n'.join([
            'HTTP/1.1 404 Not Found',
            'Content-Type: text/plain',
            '',
            '404 Not Found\n%s %s.' % (method, path),
        ])
        self.writer.write(response.encode())


async def ws_handler(websocket, path):
    pass


start_server = websockets.serve(ws_handler, '0.0.0.0', port, klass=HttpWSSProtocol)

It's unfortunate that we'd need to read the request headers twice for the WS case, and I guess there's where a PR could simplify a bit. Full working (but very hacky) code in https://github.com/tgwizard/touch-down

[Badg]

It's probably worth mentioning that load balancer health checks (on, for example, AWS, which now supports Websockets natively) are often http-only. Right now an easy workaround is to just use a second port and http.server for a trivial health check (respond to everything with 200), but it would be nice to be able to actually check the health of the websockets server itself, since that's ultimately what matters.

AWS limits successful response codes for health checks to be in the 200-399 (inclusive) range, so unfortunately you can't use the 101 response to pass the health check.

[aaugustin]

On that topic, other people have had issues with load balancer health checks that just opened a TCP connection. This worked but filled the logs with errors.