-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I can't connec to host in v1.0.X #1556
Comments
its removed (i think) |
i had the same problem, and found that you need to pass : in the ur for 1.0 to workl, where for 0.9 you pass host and port in options. |
I do not understand what you say yuryb. Might you explain me with an example or on it, thanks. |
Same problem .. :( |
I also stumbled into this problem w/ Express 4 (mac osx, chrome). I used
and then for main.js (clienside)
If it helps any, here are the headers of the request/response Request:
Response:
|
Based on some testing, it appears there is a problem with the error handling middleware that is treating socketio connections as 404. A succesful app.js that doesn't trigger this error looks like this:
|
One difference between the two is the successful one you are calling |
Another difference is that in your failing app you have io.set('transports', ['websocket', 'flashsocket', 'htmlfile', 'xhr-polling', 'jsonp-polling']); but you do not have that in your successful app. Perhaps that is what is causing the issue? |
@dougwilson Interesting, yes, removing io.set seems to fix it. It is strange though because I only added that line after doing some research after encountering this issue, where adding that line was a suggested solution, which leads me to believe it may have been a combination of things. I was trying all sorts of different things in combination at some point, eventually I must have brute-forced myself into success, minus that io.set line. The docs seem to show that io.set/io.get have been replaced by io.use as well. In regards to the position of |
OK. I looked through the socket.io code and didn't think re-ordering would be the answer, but was just pointing out a difference; socket.io will actually handle everything long before requests to it will even reach |
Definitely a good call! Thanks for taking a look into it. Unfortunately I am very late on the socket.io bandwagon so it's all new to me :-) |
an getting the same error. But I am not using any io.set calls. In my situation, I have one file, app.js, where I setup Express 4 stuff and define routes, etc. var express = require( "express" ); modules.export app; module.exports = serialListener; var app = require('./app'); var http = require('http'); DIserialPort.on('data', function(data) { I get these same socket.io errors GET /socket.io/?EIO.... 404 Is it an ordering proboem with my http listen? I have tried many permutations of the io require and listen as per the socket.io threads here. But nothing works! Please help. david |
@davidwkleber Try replacing
with
|
//var newrelic = require('newrelic');
var express = require('express');
var request = require('request');
var path = require('path');
var bodyParser = require('body-parser');
var app = express();
var http = require('http').Server(app);
var io = require('socket.io')(http);
var port = process.env.PORT || 3000;
var parUrl = 'http://192.168.199.120/mohoo-telecom-activity-4/web';
app.set('views','../html');
app.set('view engine','ejs');
app.use(bodyParser.urlencoded({extended:false}));
app.use(bodyParser.json());
app.use(express.static(path.join(__dirname,'../html')));
app.get('/ac4',function(req,res){
console.log('requesting');
res.render('begin');
});
//testing
io.on('connection',function(socket){
console.log('a user gameover');
socket.on('gameover',function(msg){
console.log(msg);
request('http://192.168.199.200/mohoo-telecom-activity-4/web/v1/user/get', function (error, response, body) {
if (!error && response.statusCode == 200) {
console.log(body);
} else {
console.log('false');
}
});
})
});
http.listen(port,function(){
console.log('listening on *:3000'+__dirname);
}); This is my code. This is ok http.listen(port,function(){
console.log('listening on *:3000'+__dirname);
}); like this is ok I am a chinese,English is very bad. |
That works for me! THANKS! @vendetta0114 |
bin/www
/lib/socket.js
This worked for me |
require('socket.io')(somemagicvar)... is undebuggable because you have 20 magic vars.
this is undebuggable and unintelligable to me. humbley, please pick one paradigm. eio.connect('localhost:8080') // 404 + XCORS error ... XCORS is undebugabble... why the app cant find its own route at thumbs down. socket was beautiful at 1.0, death by complexity. partially XCors fault imo. |
using client side: it should be also i had to DL the socket.io.js script from the downloads page cdnjs.com link, the engine-io.js repository script linked is not working. docs are not helpful. also client side
doesnt work, its too fast. docs are also wrong in a few spots using |
Y have a problem in connection versión 1.0 that I dont had in the versión 0.9.X.
I have Django running in http://app.myhost.com and my node server in http://live.myhost.com:8001
Before I could connect me to the socket.io server v0.9.x like:
Client:
io.connect(//live.myhost.com:8001);
server:
io = require('socket.io')(port)
io.set('transports', ['websocket', 'flashsocket', 'htmlfile', 'xhr-polling', 'jsonp-polling']);
but now I have a problem (not taking the live url correctly):
GET http://app.myhost.com:8000/socket.io/?EIO=2&transport=polling&t=1401468282894-1 404 (NOT FOUND)
if I rewrite (io.connect(http://live.myhost.com:8001)) now have a new problem:
XMLHttpRequest cannot load http://live.myhost.com:8001/socket.io/?EIO=2&transport=polling&t=1401468608168-1. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://app.myhost.com' is therefore not allowed access.
in debug mode to socket.io I have more info:
engine:core intercepting request for path "/socket.io/" +0ms
engine handling "GET" http request "/socket.io/?EIO=2&transport=polling&t=1401470024479-48" +0ms
engine unknown transport "polling" +3ms
The text was updated successfully, but these errors were encountered: