Note to self: next time, look at the source first

A while ago I blogged about configuring Apache to handle web sockets. Of course, haters all be like “why use Apache for this”. Well, simple really: I had time nor inclination to switch our entire environment to something like NginX.

This weekend I got fed up though, and bit the bullet. Most of it was actually surprisingly easy – there’s already a gazillion tutorials on the web on how to config NginX properly (they even have an official section in their docs on websockets).

One thing got me stuck though: my socket.io.js was loading fine, but the websocket calls themselves were returning “Bad request” errors. Upon inspecition, it was complaining about unknown session IDs. I assumed, of course, that I had missed something in the setup (like passing on query strings during proxying or something) since I could see in the logs socket.io was responding to the polling requests perfectly fine.

Of course, assumption is the mother of all fuck up.

After a good night’s sleep and digging into socket.io internals, I found out that the query parameter socket.io currently uses to convey session ids is called “sid”. (In pre-1.0 versions it was called different, since they worked for me but I desperately wanted to upgrade to 1.4.)

And you’ve probably already guessed it: I was also passing a PHP session ID to handle authentication in the backend. And it was called “sid” too. And of course had a different, incompatible value.

Duh. So anyone running into myserious “bad request” errors (and it gives quite a few results on the Googlezzz), I very much recommend sticking a few console.logs in socket.io itself to see at what point it’s failing. Chances are your setup is fine, you’re just sending it something it doesn’t expect

Leave a Reply

Your email address will not be published. Required fields are marked *