Some websocket URIs contain query string parameters

We now serve query string parameters on the wss:// WebSocket URIs produced by rtm.connect and rtm.start.

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.

Known issues

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.

What's changing?

Previously, rtm.connect and 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 ?dp=1, included.

New URIs with query string parameters:

wss://mpmulti-2323.lb.slack-msgs.com/websocket/iSaBellRinging--4Hclub-TKOmac-ozma-gr12-tAbsco_3gP551gB0=/3?dp=1

Original URIs without parameters:

wss://mpmulti-7272.lb.slack-msgs.com/websocket/iSaBellRinging--4Hclub-TKOmac-ozma-gr12-tAbsco_3gP551gB0=/2

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.connect or rtm.start again, it will likely become stuck in an endless loop, resulting in rate limiting and preventing further connections.

What isn't changing?

Nothing else about the RTM API or WebSocket connections or other platform features are changing.

How do I prepare?

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.

When is this happening?

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.