I use IE 10 to run Meteor project with IP Address but it error in console log
"SCRIPT12008: WebSocket Error: Incorrect HTTP response. Status code 403, Forbidden"
I test uncheck "Use a proxy server" in Internet Option it work, but my office must use proxy server.
How i cant fix this problem ?
Thank you every much
Your web proxy must support websockets to use them. Meteor will automatically fall back to long polling over http for cases like this. You can still use everything as normal but it'll take a bit longer to load (its very slight).
This error comes about because meteor is trying to use websockets and if it fails it falls back to long polling.
If you know you always want to use XHR/Longpolling without trying websockets start meteor with DISABLE_WEBSOCKETS as an environment variable
Related
I am trying to build a system using Socket.io and YARP. Yarp is functioning has a Reverse Proxy to all my Services.
When trying establish a connection to my socket.io service, through yarp, I am getting connection_error:
I noticed there are proper configurations used in other Reversed Proxy solutions that are well documented in Socket.io website:
https://socket.io/docs/v4/reverse-proxy/
However, I can't "translate" what they are doing to YARP. Does anyone know if this is possible?
Thanks in advance
I guess stackoverflow was my rubberduck this time...
I checked in postman the request that was being made through my Yarp Server and turns out it wasn't even hitting the correct path. For yarp to connect to a socket.io server you have to use this kind of path in your configuration file:
It seems that a sokcetio request uses it's own path, so you have to make your reverse proxy match the beggining "socket.io/"
I'm starting with Websockets and I have a problem.
I have a sails.js application that uses sockets to update the client side.
On the client side it makes an API call using socket.get("/api/v1/actor...") to bring all the items of the database. When I see what the WebSocket's traffic on the Chrome console:
As you can see, the connection has been established and the API call has been correctly done through the socket.
The problem is, there is no answer from the server, not even an error.
If I make the same API call using ajax, I get response, but it doesn't work using WebSockets.
Any idea what might be producing this behavior?
EDIT: I add here the code here that processes the request and this one here that sends the request, but the problem is that it never execute this code. I think we we are closer to the find the cause, since we think it has to do with a network problem. We figured there is an F5 reverse-proxy which is not properly set up to handle websockets
The answer didn't make any sense now that I've seen the code that's why I've edited it. I only answered because I could't comment on your question and ask you for the code.
Your calling code seems correct and the server side of things the process of response should be handled automatically by the framework, you only need to return some JSON in the controller method.
I instantiated a copy of the server (just changed the adapters to run it locally) and the server replied to the web socket requests (although I only tested the route '/index').
Normally when the problems are caused by a reverse proxy the socket simply refuses to connect and you can't even send data to server. Does the property "socket.socket.connected" returns true?
The best way to test is to write a small node application with socket.io client and test it in the same machine that the application server is running, then you can exclude network problems.
I'm trying to diagnose an issue whereby an embedded device running an HTTP client to issue requests to a Node.js Web application running on Heroku is receiving empty responses with status code 400.
The problem I'm facing is that the presumably failing requests do not even appear in the Heroku logs, so it's certainly not the Web application code returning those 400s.
On the other hand issuing requests to the Web application from a browser works just fine and the requests do appear in the Heroku logs.
I'm trying to figure out whether the embedded client is really sending requests at all and I'm wondering if there are any reasons why Heroku might send back those 400s without the requests even appearing in the logs.
The cause was related to a badly implemented HTTP client in the device that was issuing requests omitting the host header.
Adding the header solved the problem.
I am working on a pyramid realtime app that would benefit from utilizing websockets. I found that the gevent-socketio library would probably be best for my purposes.
When testing locally on my PC, the websocket transport is used and runs just fine. However, when testing on a server, the handshake fails reporting a 401 response. It then falls back to a long polling transport, which works, but I would really benefit from the speed of websocket.
This makes me believe that there is some kind of authorization issue happening since I am not connecting to the local machine anymore, but I am at a complete loss as to where to look for help.
EDIT:
Now the issue was narrowed down to the fact that we were using mod_proxy, a lighttpd module, to instance the server for development and production. Is there any work around for proxying or do we have to a abandon the idea of server instancing? Ideally we would like to have some way of authorizing users to access our development server, which is how we had it set up with mod_proxy.
I've been using SignalR successfully for some time using serverSentEvents transport. I've just installed my application on Windows Server 2012 RC and now when I connect SignalR is using websockets (as you'd expect).
It appears to work OK except there is a continuous stream of websocket traffic between server and browser - about once a second it's sending about 90 bytes.
From the debugger window in Chrome, it looks like it's sending a connection upgrade request each time.
I am successfully receiving messages sent by the server, but I seem to be worse off than when using long polling.
The browser is Chrome version 19.0.1084.52.
Any idea why this is happening?
This was down to my own stupidity - but I thought I'd answer in case anyone else has the same problem.
I had built the solution SignalR.Hosting.AspNet instead of SignalR.Hosting.AspNet45
So the method AcceptWebSocketRequest was throwing a NotSupportedException; because the client websocket upgrade failed, it just tried again about a second later.
I guess the client could show an error or something in this case to aid debugging.