Mattermost, Inc.

Websocket error code=500


i am getting the below error on my mattermost

[EROR] websocket connect err: websocket: could not find connection header with token ‘upgrade’
[2016/09/01 09:53:28 BST] [EROR] /api/v3/users/websocket:connect code=500

can anyone help with this . we are running of HTTP only

Hi @goa31

what browser are you using? Also, are you using Mattermost behind any reverse proxy or are your users connecting directly?


the user with the issue is using Firefox on ubuntu and we don’t use a reverse proxy. we have an ip table rule to forward port 80 to 8065.

also the user uses a client and also gets the same error

So it’s only one user having this problem?

looks like it so far

if it’s only happening with one user, it sounds like there’s something specific to the user’s machine that must be causing this behavior. Odd that the header would be stripped from the request. Is the user’s desktop client up to date?

Here’s something to consider: check to see if the client is actually sending the “upgrade” header. The easiest way to do this is either through Firebug OR through the “Live HTTP Headers” extensions for firefox. Here’s an example of what my client produces when attempting to establish a connection to the web socket.

GET /api/v3/users/websocket HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Sec-WebSocket-Version: 13
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: UbRTgCWQQoPkqcWcGnsZHA==
Cookie: _ga=GA1.2.103658428.1458591402; __utma=87737482.103658428.1458591402.1458591411.1458591411.1;|utmccn=(referral)|utmcmd=referral|utmcct=/; MMAUTHTOKEN=bngkb16d6pyqmffukcoaep6quw
Connection: keep-alive, Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket

HTTP/1.1 101 Switching Protocols
Upgrade: Websocket
Sec-WebSocket-Accept: f/vZdmO8Y0MLbc8Zta7C1Mq+BvU=
X-Powered-By: ARR/3.0, ASP.NET
Connection: Upgrade
Access-Control-Allow-Origin: *
Date: Wed, 07 Sep 2016 14:19:36 GMT

Do you see the client producing the header?


we get the below

Host: chat.nap
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Sec-WebSocket-Version: 13
Origin: http://chat.nap
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: bTn6SYJm/GIb0MmQRsgOhw==
Cookie: MMAUTHTOKEN=8ypgar7zi3bkdefrhgwbpxkfta
Connection: keep-alive, Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket

we have realised that when we go through the url with the port the error has gone away . any ideas what is causing this

Hmmmm. its interesting that only one client is affected… and I imagine youre using the iptables on a gateway and not on this clients machine? Other folks are leveraging the same forwarding?

There is code w/in MM that constructs a URL for the websocket, but since the error itself implies that it’s receiving the request (at the appropriate endpoint), yet missing headers, it’s as though the headers are being stripped downstream…

Have you made any progress on this in the past 24 hours?

I’m not too experienced w/ Linux specifically, but honestly I’d recommend using nginx to handle your proxying and port translation, in lieu of iptables.

Also, somebody on these forums had an issue w/ an anti-virus client causing issues w/ connecting to a websocket. Is it possible that there is something running on this machine that is blocking websockets on standard ports (like 80)?