Neko without websockets?

[CodeSource1234]

Hi:

Thank you for making Neko. It's an awesome piece of software.

I currently have Neko built and installed successfully. My test behind a network that allows websockets was successful.

The network I would like to use Neko under has a strict firewall that rejects Websockets (prevents the HTTP upgrade).

Is it possible to configure Neko for use without websockets?

I was hoping this was possible since WebRTC is allowed under this network.

If this is not possible with Neko, do you recommend any other similar software (remote desktop) that will work without websockets? Currently, I can only get Apache Guacamole to work without websockets but it's unbearably slow.

Thanks.

[m1k1o]

Hi. It could be definitely changed to work like that, but that change would not be trivial.

Would SSE (server sent events) be allowed? That could simply a lot.

[CodeSource1234]

Thanks for the response.

I tried some SSE sites on the network and SSE seems to work.

From what I can tell, most other web protocols have worked. Popular media websites work (youtube, etc). Websockets seem specifically targeted.

I wouldn't ask you to make changes to your software just for this since I feel it's not common to have all websockets blocked.

I was hoping maybe there is a way to use Neko currently without websockets.

Thanks!

[m1k1o]

Neko uses gorilla/websocket so maybe there exists a variant of this library that would not use webosckets but instead a combination of HTTP Requests + SSE. It could be then added by go replace as 1:1 replacement for the dependency.

On the javascript part, there could exist a polyfill that would again implement the javascripts WebSocket API but replace it with custom code that could communicate with the modified server counterpart.

Not sure if something like this exists, but if not it would be probably a very good way to solve this problem for any application, not just neko.

[CodeSource1234]

I wish I was more knowledge on web development or I would offer my help. I'll keep an eye on Neko and see if something like this pops up.

Thanks!

[Technetium1]

SSE doesn't have a way to replace 1:1 as mentioned. Especially with it only being server to client, so I don't think such a library variant with those modifications would exist. I also see potential for pain when straying from widely accepted solutions.

@CodeSource1234 This doesn't make much sense:

I was hoping this was possible since WebRTC is allowed under this network.

The signaling for WebRTC is almost ALWAYS over WebSockets... Open your developer tools, go to the network tab, reload page, and see if you can find the upgrade request. It should be a GET request with status 101 for an upgrade.

The easy fix would be to use a VPN. You can run your own with something like https://shadowsocks.org or https://www.v2ray.com/en and generally bypass most firewalls. Mullvad can be a legitimate paid option. Pay attention to setting the advanced options to enable any necessary bypasses like connection port or Shadowsocks.

[m1k1o]

SSE doesn't have a way to replace 1:1 as mentioned. Especially with it only being server to client, so I don't think such a library variant with those modifications would exist. I also see potential for pain when straying from widely accepted solutions.

Thats why I mentioned HTTP Requests + SSE.

• Traditional HTTP request for Client to Server communication.
• SSE for Server to Client communication.

Socket.io can do that already and work even in networks where no WebSockets are available. Maybe there exists alteady some Go alternative.

The idea of having alternative to websockets is already outlined in #371 but currently there was no reason to implement it as in almost every network where WebRTC is enabled also Websockets are.

[Technetium1]

I notice you didn't add HTTP/3, maybe notice https://github.com/quic-go/quic-go? Since you are doing a major rewrite, it may be interesting to consider alongside WHIP/WHEP.

Socket.io can do that already and work even in networks where no WebSockets are available. Maybe there exists alteady some Go alternative.

Socket.io is an old, unique beast. It existed between different eras of real-time communication, which is partly the reason for its popularity and active maintenance. Asking for similar in Go is intensely unlikely. I don't see a world where you can get such functionality without doing a lot of work yourself. I look forward to anyone's ideas and any links.

Thanks for mentioning the related issue, I've subscribed to notifications.

[CodeSource1234]

The signaling for WebRTC is almost ALWAYS over WebSockets... Open your developer tools, go to the network tab, reload page, and see if you can find the upgrade request. It should be a GET request with status 101 for an upgrade.

On the restricted network that I'm dealing with, whenever an HTTP upgrade is attempted for a websocket, I see this response coming through in the Firefox debugger (this is with HTTPS/TLS):

NS_ERROR_WEBSOCKET_CONNECTION_REFUSED

Also, I've tried using curl on a linux machine under this network with no local firewall to simulate a websocket request (without HTTPS/TLS) and received a kickback page saying "websockets are blocked" from the back-end/remote firewall, which is McAfee Web Gateway (Trellix).

I've read that upgrade header requests should be hidden in the TLS but, if that is the case, I don't understand how these upgrade requests are blocked.