[Monitor Type] Web Socket Support

[ImmaZoni]

Is it a duplicated question? Please search in Issues without filters: https://github.com/louislam/uptime-kuma/issues?q=

I have not been able to find this feature request prior.

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

I am working on a Blockchain project, and while a server/ip/port may still be up and open it does not necessarily mean that the blockchain is working properly. In my use case, I would like to be able to do a WSS call and verify the response is what is expected.

Describe the solution you'd like A clear and concise description of what you want to happen.

_WS/WSS added as an item type. Support to make a request via the specified WSS server and verify the response, similar to how the HTTP(S) - Keyword monitor type works.

(this next part is a want, not a need) This is a stretch, but the ability to perform operations on the response to test the next response would be amazing, for example, if I am wanting to make sure a counter on the WSS server went up I could to a check such as Last # < New #. or even just +1 the number like its a for loop or something. _

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Ive attempted to use the HTTP/TCP/Port options but they all fall short because of the nature of how WSS works, due to the fact that it is an HTTP connection that is then upgraded to a TCP connection, it is in this middle ground of item types currently supported within Uptime Kuma.

Additional context Add any other context or screenshots about the feature request here.

This is a major improvement that will allow uptime Kuma to be used as an API status page as well, allowing even further integration within any service needed. Additionally, if you know of a way to get this to work with the current implementation I would love to hear it :)

[fcqpl]

+1 for websocket and socket.io support

[deefdragon]

I am honestly unsure how good WS support would be implemented other than allowing arbitrary code to be executed on the server to deal with messages, which can be a bad idea for several reasons.

As for connecting, and then just dropping it, I think its feasible, but it feels wrong to implement the monitor like that.

[4F2E4A2E]

I think that a simple, http upgrade to websocket would be feasible and of good help to uptime-kuma users and websocket lovers.

e.g.:

curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" -H "Host: ws.ifelse.io" -H "Origin: https://wws.ifelse.io" https://ws.ifelse.io
HTTP/2 200 
content-type: text/plain
date: Wed, 05 Jan 2022 17:30:20 GMT
content-length: 513
server: Fly/e3ffe548 (2022-01-04)
via: 2 fly.io
fly-request-id: 01FRNMN9RYW6CB2MYKFDSQ3TFJ

Request served by 125363a3

HTTP/1.1 GET /

Host: ws.ifelse.io
Accept: */*
Fly-Forwarded-Ssl: on
User-Agent: curl/7.77.0
X-Forwarded-Ssl: on
X-Forwarded-Port: 443
X-Request-Start: t=1641403819806463
Fly-Client-Ip: X.X.X.X
Fly-Forwarded-Port: 443
Origin: https://wws.ifelse.io
Fly-Forwarded-Proto: https
X-Forwarded-Proto: https
Fly-Region: fra
Fly-Request-Id: 01FRNMN9RYW6CB2MYKFDSQ3TFJ
Via: 2 fly.io
Fly-Dispatch-Start: t=1641403819806663;instance=125363a3
X-Forwarded-For: X.X.X.X, X.X.X.X

Or maybe add support for ws directly without upgrading through http:

# can be run inside the browser console
const ws = new WebSocket('wss://ws.ifelse.io');
ws.onopen = () => {
    console.log("http upgrade successful");
    ws.close();
};
ws.onclose = () => console.log('close successful');

[ImmaZoni]

Thanks for this, ill give it a shot when I get a chance!

Happy New Year!

[ImmaZoni]

#518 Will close this.

[dskvr]

#518 was closed

[4F2E4A2E]

@dskvr please help me out understand, is there a way to monitor websocket connections now?

[tdolega]

Any updates on this?

[CommanderStorm]

Any updates on this?

Nobody has contributed a monitor until now. If you or somebody else decides to take this up, please implement the core part of the monitor as in https://github.com/louislam/uptime-kuma/pull/3178 (=> not monitor.js, but using MonitorType). https://github.com/louislam/uptime-kuma/pull/3119/ might also be a good example.

Here is our contribution guide: https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md

[CommanderStorm]

Also note that another user (@dskvr) on a related issue has commented on the following:

Not sure how Uptime Kuma expects users to test a websocket, particularly in the generation of a Sec-WebSocket-Key header.

=> I am not shure if this is a blocker