Run HTTP and WS servers on the same port

[iameli]

Do you want to request a feature or report a bug?

Feature

What is the current behavior?

HTTP and Websockets are on different ports

What is the expected behavior?

It'd be nice to have them be able to run on the same port, especially when setting up production graph-node servers that are only exposed over HTTPS.

I'm currently working around this with a mildly-hilarious series of hacks... first off, I run graph-node with --ws-port=443, which tricks GraphiQL into using that for websocket connections. Then, I'm running an nginx proxy in front of graph node that routes connections appropriately:

events {
  worker_connections  4096;
}
http {
  upstream graph {
    server 127.0.0.1:8000;
  }

  upstream websocket {
    server 127.0.0.1:443;
  }

  # map to different upstream backends based on header
  map $http_upgrade $destination {
    default graph;
    websocket websocket;
  }

  map $http_upgrade $connection_upgrade {
      default close;
      websocket upgrade;
  }

  server {
    listen 80;
    location / {
      proxy_pass http://$destination;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection $connection_upgrade;
    }
  }
}

That takes care of sending HTTP requests with Upgrade: websocket to the WS server and normal HTTP connections to the normal HTTP server. The net result is a node and GraphiQL that handles both WS and non-WS HTTP connections over HTTPS: https://graph.livepeer.org/subgraphs/name/livepeer/graphql?query=query%20%7B%0A%20%20transcoders%20(first%3A%2025)%20%7B%0A%20%20%20%20id%0A%20%20%7D%0A%7D

But it'd be nice if this was possible to do on the server itself.

[0xTimepunk]

Can anyone comment on the status of this?

[leoyvens]

At the moment you have to run nginx in front of graph-node to expose subscriptions and queries on the same port.

The support for subscriptions in graph-node has issues and we currently recommend utilizing polling. Subscriptions will be supported in a different form in the decentralized protocol.

[0xTimepunk]

At the moment you have to run nginx in front of graph-node to expose subscriptions and queries on the same port.

The support for subscriptions in graph-node has issues and we currently recommend utilizing polling. Subscriptions will be supported in a different form in the decentralized protocol.

Thanks for the answer @leoyvens. If I start graph-node with 443 ssl port (--ws-port=443) as per @iameli 's suggestion, I ran into the following error

I have tried to elevate permissions of cargo to allow this, without success, so I wonder how you can bind to that kind of low numbered port

sudo setcap 'cap_net_bind_service=+ep'which cargo

Another thing I have tried is running graph-node like this:

sudo ./target/debug/graph-node --postgres-url postgresql://USER:PW@localhost:5432/graph-node --ethereum-rpc 'mainnet:http://127.0.0.1:8545' --ipfs 127.0.0.1:5001 --ws-port=443

But then I get this:

[leoyvens]

@j-mars Looks like the port is already in use by another process in your system. That issue is not specific to graph node.

[Aminechakr]

2 years passed, any feedback? other consumers still face some problems. WS and GraphQL are not working when dealing with a reverse proxy to protect Graphnode instances with SSL over one single port & from DDoS attacks.