I need something like this for Sparkpost. I'm on an awesome legacy free plan that gives me 100k emails a month so I feel kinda stuck using them. On Mailgun that would be $79/month.
Socket.io bad requests on NodeBB 0.6.1
Hm... that's quite weird, I don't know why your version of Safari doesn't seem to work with websockets...
Running the latest Safari...
Anyway, the issue seems to have magically disappeared in 0.7 dev build.
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/)?
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.
What Safari version are you using? Possible it does not support websockets...?
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.
@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.
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.
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...
@markkus This is my nginx config:
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.
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...