I'm trying to get websockets to also work with node-http-proxy. The difference is i'm using a proxytable:
var options = {
router: {
'a.websterten.com': '127.0.0.1:150',
'b.websterten.com' : '127.0.0.1:151',
}
};
var server = httpProxy.createServer(options);
I tried:
server.on('upgrade', function (req, socket, head) {
server.proxy.proxyWebSocketRequest(req, socket, head);
});
But it doesn't seem to work. A quick check to see whether websockets work shows I get Unexpected response code: 400 from Chrome (works fine if I go directly)
Also doing a couple of checks server.on('upgrade',.. doesn't fire on a websocket request
How can I get my proxy server to route websockets correctly?
I've also tried this on node 0.8.23 as well as node 0.10.x (the later versions of node have a memory leak issue, but it wont work on 0.8.23 either)
When you use httpProxy.createServer(), it's not necessary to handle the upgrade event because http-proxy handles it automatically. Thus, your server.on('upgrade', ...) never fires because http-proxy is already handling it internally.
The only time you need to do server.on('upgrade') is when you pass middleware functions to httpProxy.createServer or if you've manually created the server with http.createServer().
In other words, websockets should "just work" through the proxy in your configuration.
However, WebSocket support in http-proxy is currently broken on node v0.10.x because of streams2 (the stream APIs in node core were completely rewritten in 0.10). Also, the most recent release of http-proxy (0.10.2) is broken in node v0.8 because of a botched fix for the streams2 issue.
So you have two options:
Wait for http-proxy to rewrite its internals to cope with streams2.
Downgrade to node v0.8.23 and http-proxy 0.10.1. (At least until #1 happens.)
(You can install old versions of npm modules by running npm install http-proxy#0.10.1.)
Related
We've been using node.js 16.16.0 with Vite(our monorepo is managed using rush with pnpm under the hood), and we were serving some files using server.fs configuration(https://vitejs.dev/config/server-options.html#server-fs-allow).
In node 16.16 everything works as expected, more or less, allow option as well as deny option serve their purpose. However, after upgrading node to 18.13, the functionality of serving files from filesystem does not work at all, and there is very little to work with.
Every request for specific file, that works in node 16.16 returns with Error: connect ECONNREFUSED 127.0.0.1:5001 where 5001 is our dev port. Host and port are set correctly.No suspicious error messages in the console etc.
It looks like the files are not beeing served under this urls at all. Using deny changes nothing, still the response is ECONNREFUSED(in 16.16 it's 403 Restricted).
I upgraded Vite to the newest version, error still the same.
I'm slowly running out of ideas, I will appreciate any help.
Ok, I found the issue... It's so dummy and has nothing to do with Vite... In node 17+ they are no longer treating IPv4 as default, but they are taking the OS system configuration into account.
Node.js no longer re-sorts results of IP address lookups and returns them as-is (i.e. it no longer ignores how your OS has been configured). You can change the behaviour via the verbatim option to dns.lookup() or set the --dns-result-order command line option to change the default.
It means that application on this node version will no longer serve anything on 127.0.0.1(IPv4), but on ::1(IPv6). Switching from '127.0.0.1' to 'localhost' did the trick in my case.
Im trying to install node.js to shared dreamhost. I have followed the directions for Dan dean here http://dandean.com/nodejs-on-dreamhost-shared-server/
but when I go test,
$ node --version
Then it says:
-bash: node: command not found
I follow the step by step, this is the correct way to install the node in the shared server?
Dreamhost has supported Node.js on shared host recently.
I put the following source code in app.js and it works.
var http = require('http');
var server = http.createServer(function(req, res) {
res.writeHead(200, { 'Content-Type': 'text/plain' });
res.end("Hello World!\n");
});
server.listen(3000);
But it seems to be unstable when I try to restart it.
Check https://help.dreamhost.com/hc/en-us/articles/217185397-Node-js-overview for details.
You may want to look into nvm when installing Node somewhere else than your local environment.
Check out my blog post on nvm:
http://mycodesmells.com/post/node-version-management/
Sometimes, installing node.js on certain linux instances creates the command nodejs instead of node. Try nodejs --version. If you want to be able to use node as the command, simply create a simlink to /usr/local/bin/nodejs for /usr/local/bin/node.
Currently DreamHost says “Node.js can be installed onto Shared, VPS, and Dedicated Servers.” However, for shared servers, currently Node is only supported using Passenger, and the version of Passenger “running on DreamHost servers does not currently function with Node.js versions 14+” as of March 1, 2022. They have not shared a target date for allowing newer versions of Node.
For more instructions, and up-to-date compatibility information, see their support documentation on Node.js at Dreamhost.
It may not have been the case at the time this question was posted, but Dreamhost does not allow compiling or running nodejs on shared hosting.
Can Node.js be used on shared servers?
No. DreamHost does not support Node.js on shared web servers, as the security setup on DreamHost shared servers is incompatible with compiling or running Node.js.
Furthermore, Dreamhost claims they will ban users who attempt to do so:
If you try to compile Node.js on one of the shared web servers, your user will automatically be banned through grsec (taking down all the PHP websites that run under that user) and the server will have to be rebooted before your user can be unbanned. If you do it one more time, you will be forced to move to a VPS.
I've had Dreamhost shared hosting for nearly 10 years, but they don't allow long-running processes. This also prevents common tools like composer from running if they take more than a few seconds. I recently moved to a VPS because of this.
https://help.dreamhost.com/hc/en-us/articles/217185397-Node-js-overview
I got a Meteor project from a friend who develops on MacOS.
When trying to run it, I get:
This project uses METEOR#1.0.2.1, which isn't available on Windows. To
work with this app on all supported platforms, use meteor update
--release METEOR#1.2.1 to pin this app to the newest Windows-compatible release.
When running it, I get:
While checking for cfs:gridfs#0.0.27: no compatible binary file
found...
Then, when I try to override (use run instead of update), without actually updating, it starts proxy and Mongo, but then breaks at, but skips the first error
While building package npm-container: error: No plugin known to handle
file '../../packages.json'. If you want this file to be a static
asset, use addAssets instead of addFiles; eg,
api.addAssets('../../packages.json', 'client').
I read that this error is fixed by updating meteorhacks, but when I try to, I get the Meteor version conflicts (see very first error) and I have no idea how to break out of the loop.
Can someone shine some light on how to fix any of these error?
I'm trying to run socket.io and I'm getting a bunch of these:
http://domain.com:8080/socket.io/?EIO=2&transport=polling&t=1401421022966-0 400 (Bad Request)
This is the response I'm getting:
{"code":0,"message":"Transport unknown"}
I can't find any reason. I read somewhere that it might be misinterpreting the client, but that's about as far as I could get.
I had the same issue after upgrading from 0.9.x to 1.x.x. Shortening the long story, I would set transports to ['websocket', 'polling'] and then the error...
when you config your server to use specefic transpors you should set the same config on client side to...
server
var io = require('socket.io')(server, {'transports': ['websocket', 'polling']});
client
var io = io( serverUri, {'transports': ['websocket', 'polling']});
I had the same issue,after upgrading from 0.9.x, turns out my server config was set to ['websocket', 'jsonp-polling'] which was valid in 0.9 but the default config for the client and server is now ['polling', 'websocket'].
Removing my server config got me up and running.
The config is now documented in engine.io (https://github.com/automattic/engine.io), the new transport layer introduced in 1.0 - in particular this line:
transports ( String): transports to allow connections to (['polling', 'websocket'])
i had the same issue:
Getting the latest socket-client.js and using these file on clientside, solved this problem for me.
This happened to me when I served the socket.io.js script myself.
I had to go copy node_modules/socket.io/node_modules/socket.io-client/socket.io.js to where I was serving it up.
Try this configuration on server side
const io = require('socket.io')(server, {
cors: {
origin: "http://localhost:8100",
methods: ["GET", "POST"],
transports: ['websocket', 'polling'],
credentials: true
},
allowEIO3: true
});
My solution was to upgrade node.js to latest (0.12.0 at the time of this post). Originally node.js was installed as a part of a bundle. Once I uninstalled that node.js coming from that bundle (Aptana 3 bundle, node.js was somewhat behind), and installed the latest from node.js's website, things started working finally.
I was experimenting with React.js. I spent several hours debugging the phenomena, I've found build errors in socket.io, specifically about socket.io-client, it tried to invoke Visual Studio MSBuild unsuccesfully. Which is sad, the error occured with node-gyp too. Apparently socket.io-client is not needed to run/serve my examples, and seems like these unfortunate errors (which lured me into an endless forest) can be ignored.
(I noticed also a module while installing webpack-dev-server, which is Darwin only (a.k.a. Mac OS X). That's fortunately an optional dependency. It's frightening though: I know that Apple is very hipster, but the majority of the world is non Mac.)
I fixed it acting in my server.js
the io instance is initialized as follow:
const io = socket.listen(httpServer, { serveClient: true })
Before I had { serveClient: false }, because otherwise, I was getting an error. But actually, if you want that your client takes io from the node instance you have to serve it.
UPDATE: At the end.. you want to simply have const io = socket.listen(httpServer)
In this way is going to be true by default.
Ok so I have read through the Socket.IO docs and I am still a little unsure of a couple of points:
The documentation says...
To run the demo, execute the following:
git clone git://github.com/LearnBoost/Socket.IO-node.git socket.io
cd socket.io/example/
sudo node server.js
Now I don't know what this means at all! I think it may be command line interface. I of course have access to this on my localhost, but my online hosting package is a shared LAMP setup. Meaning I don't have access to the root command line (i think).
How do I actually setup socket.IO, is it impossible on my shared server package?
Appreciate any help...
W.
If you aren't familiar with node.js or with basic command line usage then I would suggest that you use a hosted WebSockets solution like pusherapp. Trying to learn WebSockets, and Node.js, and the Linux command line all at once is going to lead to a lot of frustration. Take a look a pusherapp's quick start guide, it's very easy to get started. You can have 5 simultaneous connections with a single application for free (I'm not affiliated with pusherapp).
Updated (with inline answers to questions):
If you are going to go the direction of running a Socket.IO application:
You don't technically need git since you can download node.js and Socket.IO from their respective download links on github.
You don't actually need a LAMP server to use Socket.IO. By default Socket.IO functions as a simple webserver in addition to a WebSockets server. If you want server side scripting then you might want Apache with mod_php, mod_python, etc.
You don't technically need a dedicated server or even root access. You do need a system where you can have long running process. And if you want the service to start automatically when the system is rebooted, you probably want to add a startup file to /etc/init.d, /etc/rc.d which will require root access. Both node.js and Socket.IO can be installed and run from a normal home directory. If you want to run Socket.IO on a standard port like 80 or 443 then you will need to run it with root privilege.
Node.JS scales quite well so Socket.IO will probably scale pretty well too.
It's not a simple matter to get everything setup and working, but if your goal is a free solution for web serving+WebSockets then Socket.IO is probably is good route to at least explore if you are brave.
First you'll have to determine if your host supports SSH. Sometimes they don't by default on shared hosting, but if you ask they can turn it on. If it does you'll use some sort of SSH client to connect to it. Putty for windows is the most common. Then you'll use git, which is a source control program. Which you'll probably have to install on your host, which may or may not be allowed. If you can, this can be accomplished a number of ways, you'll want to read the git documentation, it will depend largely on what linux distribution you're running. CD is change directory, basic command line stuff. sudo on the last line is telling the system to run the command as root, which it will ask you the password for, which you may not have access to on your host. Sounds like you're gonna have an uphill battle on shared hosting. You may want to opt for a VPS instead.
If your shared host is a LAMP system with no command line access you're not going to get very far with Socket.IO. The instructions you posted assume you have command line access and that you've installed the node.js runtime on your system.
If you really want to try this I recommend you get a VPS of your own (I use prgmr.com) to test it out. For what it's worth I found the Socket.IO platform pretty nice to use once I got it up and running.