Some websocket URIs contain query string parameters
While the specification for WebSockets explicitly allows query string parameters, some third party libraries not fully implementing the spec may handle these parameters incorrectly, stripping them off and invalidating your attempts to open a connection.
Though we didn't anticipate issues sending query strings in websocket URIs, some libraries and frameworks may need tinkering with.
- Use Slack API in Go AKA
github.com/nlopes/slack? Update to the latest version of this Golang project to resolve connection issues. A recent commit merged with master fixes websocket URI handling.
rtm.start would only yield websocket URLs containing protocol, host, domain, and path elements, but no query parameter components.
Now Slack will often return a WebSocket URI string with a query string parameter, such as
New URIs with query string parameters:
Original URIs without parameters:
You must preserve these parameters when directing your WebSocket client to open the connection.
If your code or library doesn't preserve the query string, the connection will fail. If your library automatically attempts to retrieve a new websocket connection by requesting
rtm.start again, it will likely become stuck in an endless loop, resulting in rate limiting and preventing further connections.
Nothing else about the RTM API or WebSocket connections or other platform features are changing.
If you're sure this problem is affecting you, upgrade any client libraries you depend on. If the issue is still unrectified, consider diving in to the code you rely on and examine how websocket URIs are treated after reception. If the URIs are truncated, rectify it by preserving the URI exactly as returned by the API.
These changes to websocket URIs have been slowly trickling to production over the past several weeks, beginning in December 2017.
Still having trouble or want to help others resolve issues like this? Let us know what you've found out.Review other recent updates