WebSocket reserved bits error

[dpetrovics]

Hi,

I am using http-kit 2.1.13 for our app running on Heroku. We make use of websockets to deliver data from server to client, with Carmine.

It works most of the time, but we occasionally get the following error about reserved bits:

WebSocket connection to 'wss://staging.paddleguru.com/results/stream' failed: One or more reserved bits are on: reserved1 = 1, reserved2 = 0, reserved3 = 0

Any ideas what could be causing this?

[shenfeng]

It seems that your client try to use some extension: http://www.rfcreader.com/#rfc6455_line1777

http-kit does not implement extension yet.

Is the error message report by Chrome? Any steps to reproduce it?

[sritchie]

Hey @shenfeng, I'm on this problem too. It seems to happen sporadically. Could it have something to do with the way we're initializing the socket?

(defn init-socket []
  (.log js/console "Initializing socket.")
  (reset! ws (let [socket (js/WebSocket. ws-url)]
               (set! (.-onmessage socket)
                     (fn [msg]
                       (put! receive msg)))
               (set! (.-onopen socket)
                     (fn [_]
                       (.log js/console "Websocket connected.")))
               socket)))

I'm worried about a race condition with us swapping out the onmessage, onopen functions like this. Is this the proper way to do things?

[shenfeng]

websocket works in the following steps:

1. A handshake message encode in HTTP protocol is sent to server (js/WebSocket. ws-url)
2. server looks at the message, find that the client want to upgrade to WebSocket. server than respond a message says 'ok, upgrade'. this message is encoded in HTTP protocol
3. client receive the message. onopen 's callback will be triggered.
4. client and server then communicate using WebSocket protocol bidirectional. server use on-receive and send!. client use onmessage and send.

Is there any chance that a message is sent to server before onopen.

Hi, @sritchie looking at the code, the socket is returned from init-socket. It may be used before onopen.
I suspect Chrome(or Firefox) will report an error, If you do so, not sure.

[sritchie]

It's Chrome we're talking about... I'll keep an eye out for the error. It may be that we were screwing up websocket support in Heroku.

[dpetrovics]

Hi @shenfeng , thanks for the quick update. We are using Chrome-- the client seems to initialize the websocket fine and begins to receive messages OK. However, when there is a somewhat lengthly pause in messages (around a minute), we can see the 'reserved bits' error in the browser. We're still digging....

[shenfeng]

Hi，

there is a somewhat lengthly pause in messages (around a minute)

when pause, does http-kit respond any further request? Does http-kit failed?

You can try to dump the jvm stack by using
jstack pid to see the stack trace.

[sritchie]

Hey @shenfeng, we'll do some more research this coming week. We've been sending a keep-alive ping from the client to the server every thirty seconds, but Heroku has a 55 second hard limit on connections, and I'm worried that what's happening is that Heroku is shutting down the websocket connection and we're getting back a response from the heroku load balancer that doesn't match the websocket protocol.

[choppen5]

@sritchie Did you resolve this? Having the same problem on heroku, sending a ping to the server from my javascript client to keep alive. Doesn't happen locally (outside of Heroku).

[sritchie]

@choppen5 we haven't had time to look into it yet, unfortunately. You've got the websockets labs enabled, right? https://devcenter.heroku.com/articles/heroku-labs-websockets

Our issue was still happening with that all configured... just want to make sure that we're both set up the same way.

[mondain]

You can get this error in Chrome if unframed data comes after the handshake, which is then followed by framed data. I just wanted to share that since I just debugged this exact issue for several hours. The implementation I started with was adding the accept string after the CRLF \ CRLF following the headers.

[dobry-den]

I sheepishly encountered this when I accidentally applied the handler to the request multiple times within my middleware:

(def app
  (-> app-routes
      ((fn [handler]
         (fn [request]
           (when ...
             (handler request))
           (handler request))))))

@mondain's comment is what compelled me to look for such a thing.

[ptaoussanis]

Hi there, is anyone still having problems with this or can the issue be closed?

[sritchie]

We're past this issue, but we had actually solved it by moving off of Heroku, so I'm not sure this gives you much signal :)

[ptaoussanis]

@sritchie Okay, thanks for the confirmation Sam!

[ptaoussanis]

Closing this issue for inactivity, please feel free to reopen if anyone has new info/thoughts to contribute.