Socket.io bad requests on NodeBB 0.6.1

Shaun

The message looks like it could (possibly) be related to security settings. Are you accessing the site from the same URL as the one shown in the error (http://[Host Address]:4567/)?

KingCat

I'm seeing this exact same error except mine didn't go away in 0.7.0-dev. I thought at first it had to do with SSL but I setup the server to accept connections directly to the nodebb server bypassing nginx completely like described here and I'm still getting them, only in safari though.

I wish I knew what the issue was dammit. This is frustrating as all heck.

julian

What Safari version are you using? Possible it does not support websockets...?

KingCat

@julien Safari Version 8.0.5 (10600.5.17)

It's supposed to be able to support web sockets, according to google anyway it does. Though I found a few posts on the github page for socket.io about safari issues that have never been solved.

KingCat

So I was completely ready to just pass it off as a safari issue and move along with my life but then I realized something obvious and overlooked. The issue doesn't occur.. AT ALL... on this site. Only on mine. That means it's an implementation problem on my end and not just a fact-of-life incompatibility between safari and node/socket.io.

I don't necessarily think it's nginx since I still got the errors when visiting nodebb directly through the ip:port. I was only getting 400 errors and not the 522 but that makes sense since it's nginx that generates the 522 i imagine.

I've got to solve this problem or it's going to consume me. I'm running the latest master 0.7.0-dev.

Plz Halp.

KingCat

@julien I created a screencast of it happening: https://www.dropbox.com/s/4hlga9ewp3neq1u/socketissue-sansnginx.mov?dl=0

Edit: I tried installing a fresh copy of nodebb on a different port and I didn't get these socket issues so apparently it's not a problem with nodebb. However, when I changed the config for this new install to use the original database the errors started coming back. I'm not sure how to debug further but It seems like something in the database is causing this problem.

Is there any way I can export the posts and re-import them into a new install? I don't want to lose all my posts.

Edit2: I was mistaken. What was happening was I wasn't getting errors on the new installation when visiting the ip:port directly however when I put the new installation behind the SSL cert and domain name it had these same errors again. I even went so far as to purchase a new SSL cert, the same one this site uses just to be sure and the errors still persist. BTW I found out the errors also happen in Opera. I will get to the bottom of this.

KingCat

Welp, I solved it.

Turns out I had the wrong directory specified in nginx for static assets. It was pointing to a different install of nodebb. For some reason that caused issues with socket.io.

Now, here's the weird thing. I only recently started using nginx to serve the assets. Recently as in like this morning. Before that I simply had a proxy pass setup and let nodebb serve the assets. I'm not sure what was causing the 400/502 errors then but I'm just glad their solved now.

markkus

@KingCat said:

Welp, I solved it.

Turns out I had the wrong directory specified in nginx for static assets.

Could you tell me exactly step-by-step what you did? Seems like the error has come back...

KingCat

@markkus This is my nginx config:

upstream io_nodes {
    ip_hash;
    server 127.0.0.1:4567;
    server 127.0.0.1:4568;
}


server {
    listen 443 ssl spdy;

    server_name forum.nzb.cat;

    access_log /var/log/nginx/forum_access.log;
    error_log /var/log/nginx/forum_error.log;

    ssl on;

    ssl_certificate /etc/nginx/ssl/forum-nzb-cat-bundle.crt;
    ssl_certificate_key /etc/nginx/ssl/nzbcat.key;

    # enables all versions of TLS, but not SSLv2 or 3 which are weak and now deprecated.
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    # disables all weak ciphers
    ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";

    ssl_prefer_server_ciphers on;

    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_set_header X-NginX-Proxy true;
    proxy_redirect off;

    # Socket.io Support
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    gzip            on;
    gzip_min_length 1000;
    gzip_proxied    off;
    gzip_types      text/plain application/xml application/x-javascript text/css application/json;

    location @nodebb {
        proxy_pass http://io_nodes;
    }

    location ~   ^/(images|language|sounds|templates|uploads|vendor|src\/modules|nodebb\.min\.js|stylesheet\.css|admin\.css) {
        root /data/nodebb2/public/;
        try_files $uri $uri/ @nodebb;
    }

    location / {
        proxy_pass http://io_nodes;
    }
}

Now when I was having the error the "root" directive of the "location" block was set to "/data/nodebb/public" which was an old nodebb installation. Updating it to "nodebb2" fixed the issue.

Like I said though, I have no idea what was causing the issue before I started using nginx to serve the static assets (which is what that "location" block does). Maybe there was a permissions issue or something? No idea.

Edit: also, I'm using nginx 1.8 on ubuntu 14.04 with nodebb 0.7.0-dev. I was also having this issue in 0.6.x but not sure if this would fix it.

markkus

@KingCat

Sadly, your solution does not work in my case .
It's kinda weird indeed - works flawlessly on Chrome, spams errors on Safari.
I'm really starting to think it's Safari's bug...