WebSocket ping API (continuing)

[bradennapier]

First of all, sorry if this is not the right place to make this comment, I got here by searching and it seems the place from what I could find.

---

Ok so this has been brought up quite a few times in many places and I wanted to revive this conversation with perhaps a more focused request to give specifics (examples below). In general the team seems to have a bias here, but I urge you to listen to the general web at a large and see the general consensus that this is a missing part of the current implementation.

Here is the situation, almost all clients outside of this API implement the WebSocket specification with the ability to use ping in the minimum. I fully understand not providing the pong handler that some libraries (mostly server libs) will also expose.

---

1. There is a disconnect from what people read and expect as possible via most implementations of WebSocket across all programming languages vs the HTML5 WebSocket API.
2. Allowing "keep alive" functionality for a client requires control of both client AND server or the server may not accept or may disconnect a user for sending an invalid packet.

• It is not fair to assume the client that wants to "stay alive" and detect its socket connection is in some way lost can simply send some random packet and hope the server won't treat this in some unknown way.
• Most, if not all public WebSocket API's do not provide a ping handling since the WebSocket RFC provides a ping, pong capability as part of the RFC - its just not possible from HTML5 connections.
• It's easy for a server provider to not consider HTML5 being a single implementation without the ability to ping for these cases and this leaves web clients out in the cold until they can write a complete clone of the ping/pong handling into their logic.

3. It causes confusion for very little reason, the arguments against it are simply not strong vs unifying what is expected on top of providing a proper mechanism for "keep alive" and/or detecting that a connection may be lost.
4. Providing server-level handling for ping / pong on top of the internal handling done by libraries is a performance hit on servers which generally use modules (C, C++, etc) but then parse messages in some implemented language. It requires they treat this special case and duplicate the logic that is already guaranteed to be implemented by the library.
5. This is especially a problem for "pubsub" style WebSockets (which are probably the most common) which have a client "subscribe" then start receiving events. In this situation, it is common for the client to subscribe then simply handle incoming events as-normal.
6. This is requiring everyone implementing a server provide a non-standard way of implementing a standard already specified in the RFC. I've seen people say to send { action: 'ping' }, heartbeat, __heartbeat__, ping, ['ping', data] --> ['pong', data] just to name a few, and each is completely subject to user-error along the way by not handling it the way the RFC already defines.

---

I am honestly extremely surprised there is such a pushback to supporting this. It leads to so many issues by people, simply read the many stackoverflow or github issues on all the libraries out there having to deal with people running into this confusion.

In the absolute minimum - some sort of keepalive feature or autoping should be available to allow the client to automatically detect stale sockets and reconnect as-necessary.

Can we please reconsider the implementation here and try to understand that modern web applications really require this type of functionality to operate smoothly and with less potential side effects and problems.

I have personally run into a good number of situations where a website was not implementing WebSocket on web properly (as my guess) and i had to refresh page before it would reconnect.

---

A Few Examples from simple search:

• why ping,pong are not exposed in websocket API? #3809
• https://stackoverflow.com/questions/10585355/sending-websocket-ping-pong-frame-from-browser
• https://stackoverflow.com/questions/46111656/must-websockets-have-heartbeats
• https://stackoverflow.com/questions/26971026/handling-connection-loss-with-websockets
• https://stackoverflow.com/questions/4282151/is-it-possible-to-ping-a-server-from-javascript
• https://stackoverflow.com/questions/49408031/websockets-in-chrome-and-firefox-disconnecting-after-one-minute-of-inactivity

[annevk]

I don't see much pushback? Also, if you could apply https://whatwg.org/faq#adding-new-features to this issue that would help a lot. It seems clear there might be some kind of problem here, but it's not at all clear what to do about it.

[bradennapier]

Thanks @annevk that comment comes from a post I was reading from an old discussion on it, happy to hear there is an open mind about the issue! I will read through that and post when I can! Thanks!

[domenic]

It's a bit unclear what this is requesting as per @annevk's 2019 comment the process wasn't followed, but I believe it has an overlap with whatwg/websockets#10 so since we are transferring issues to whatwg/websockets anyway, I will close in favor of that issue.