Unable to solve EADDRINUSE in NodeJS - node.js

I am trying to integrate the mailchimp OAuth plugin for node (https://github.com/gomfunkel/node-mailchimp/) and I keep getting an EADDRINUSE error and I am not sure what the issue is. I know what the error means I just don't know how to stop it.
My express server is running on port 3000. The mailchimp class evidently wants to spawn a server - it defaults to port 8100. I have tried changing both of these ports to no avail. What could be the issue?
Here's the route code I am using:
exports.test = function(req, res){
var MailChimpOAuth = require('mailchimp').MailChimpOAuth;
var MailChimpAPI = require('mailchimp').MailChimpAPI;
var options = {
clientId: '00000000',
clientSecret: 'abcdefghijklmnop',
serverUri: 'http://localhost',
redirectUri: 'http://localhost',
};
var oauth = new MailChimpOAuth(options);
Now my initial request works and any subsequent ones cause the error - probably encountering the already spawned server. Is that a bug in the mailchimp class that is should see if it already spawned?

From what I can tell, you're creating a new MailChimpOAuth on every request, so when your second request rolls around, you've already got a server listening on 8100.
You need to do all that setup stuff once at initialization and, in your request handler, refer to the already instantiated MailChimpOAuth instance.
As a general rule, if you find yourself doing a require(...) in code that runs more than once, your logic needs rethinking.

just run:
killall -9 node
and try it again. It worked for me

Related

jsreport Hello world

I'm trying to create my first report with jsreport. I've followed the documentation, but I'm not able to generate the most simple Hello world.
I've tried:
npm install jsreport
and then create a simple server:
var http = require('http');
var jsreport = require('jsreport');
http.createServer(function (req, res) {
jsreport.render("<h1>Hello world</h1>").then(function(out) {
out.stream.pipe(res);
}).catch(function(e) {
res.end(e.message);
});
}).listen(1337, '127.0.0.1');
The server is running on port 1337.
But if I try to open http://localhost:1337/ nothing happens. I was expecting a page with Hello world.
On the server side, I get on the console:
2018-02-17T10:55:16.009Z - info: Initializing jsreport#1.10.0 in development mode using configuration file: jsreport.config.json
2018-02-17T10:55:16.011Z - info: Setting process based strategy for rendering. Please visit http://jsreport.net/learn/configuration for information how to get more performance.
2018-02-17T10:55:16.013Z - info: Searching for available extensions in /home/jgr/WebstormProjects/GeoMasterBoard/server/
2018-02-17T10:55:16.016Z - info: Extensions location cache not found, crawling directories
Do I need a jsreport server running or this code should be enough?
I also tried to install jsreport server, following the documentation.
After jsreport start it shows on the console:
2018-02-17T10:42:46.013Z - info: Initializing jsreport#1.10.0 in development mode using configuration file: jsreport.config.json
2018-02-17T10:42:46.015Z - info: Setting process based strategy for rendering. Please visit http://jsreport.net/learn/configuration for information how to get more performance.
2018-02-17T10:42:46.023Z - info: Searching for available extensions in /home/jgr/WebstormProjects/GeoMasterBoard/server/
2018-02-17T10:42:46.025Z - info: Extensions location cache not found, crawling directories
But nothing happens when I try to open http://localhost:5488/. If I do: nmap -p 5488 localhost the awnser is:
PORT STATE SERVICE
5488/tcp closed unknown
What am I missing?
I'm using node.js v8.1.2, on Ubuntu 16.04.
your code is not working because the following reasons:
when you open your browser at http://localhost:1337/ your browser is actually making 3 different requests (1-> http://localhost:1337/, 2-> http://localhost:1337/favicon.ico, 3-> http://localhost:1337/robots.txt), not just one
the code that your are using to handle the http server is not doing a proper routing, it should process a url just once, right now it is just calling jsreport.render on every single request that goes through your server (even the ones for /favicon.ico, /robots.txt), and this is bad in the browser because as i already explained your browser makes like 3 request for a single page load.
you are using the shortcut jsreport.render in the request handling, which means that jsreport is going to try to initialize itself when your first request arrives, because of the problem explained above (not doing a proper routing in your http server) this results in jsreport trying to initialize 3 times on your first page load which leads to an uncaught exception that exits your process with no error message (we are going to update some things to better handling this exception in the future).
finally, here is some code that completes your hello world test case (with some code that filters unwanted requests like /robots.txt, /favicon.ico, but in production code you should implement a proper router logic in your http server. if you don't want to code it yourself just use something like express)
var http = require('http');
var jsreport = require('jsreport');
http.createServer(function(req, res) {
if (req.url !== '/') {
return console.log('ignoring request:', req.url);
}
console.log('request:', req.url);
jsreport
.render('<h1>Hello world</h1>')
.then(function(out) {
out.stream.pipe(res);
})
.catch(function(e) {
res.end(e.message);
});
}).listen(1337, '127.0.0.1');

Node.js server resets on user error

I’m developing a Node.js application which in a user signs up in three levels.
the problem is when a user encounters and error in any of the levels, the whole server reset and the rest of the user sessions get close.
the reason that server restarts is that I’m using forever start app to start my app,otherwise it goes down completely.
how to stop the server to stops completely when just one users
encounters any error?
how to start each users in an individual thread(by thread i mean an isolate environment)?
Considering #Michael 's answer
unfortunately that's not how Node works. An unhandled error can cause
the server to restart.
The only way is to handle execptions in a proper way. So you can check this answers comments about how to handle an uncaughtException
var handleRequest = function(req, res) {
res.writeHead(200);
res1.end('Hello, World!\n');
};
var server = require('http').createServer(handleRequest);
process.on('uncaughtException', function(ex) {
// do something with exception
});
server.listen(8080);
console.log('Server started on port 8080');

Websocket server running fine but cannot connect from client (what url should I use?)

OK this is very simple to anyone who's used websocket and nodejs.
I have created a websocket server named ws_server.js and put it in C:\Program Files (x86)\nodejs where I have installed the nodejs framework. I started the server and it is running and it says it's listening on port 8080. So far so good, I have the server running.
Now I simply want to connect to it from client code so that I can do all that lovely stuff about capturing events using event listeners etc. The problem is, embarassingly, I cannot figure out what URL to use to connect to my websocket server.
function init() {
testWebSocket();
}
function testWebSocket() {
websocket = new WebSocket("ws://localhost:8080/"); // WHAT URL SHOULD BE USED HERE?
websocket.onopen = function(evt) { alert("OPEN") };
websocket.onclose = function(evt) { alert("CLOSE") };
websocket.onmessage = function(evt) { alert("MESSAGE") };
websocket.onerror = function(evt) { alert("ERROR") };
}
function doSend(message) {
// this would be called by user pressing a button somewhere
websocket.send(message);
alert("SENT");
}
window.addEventListener("load", init, false);
When I use ws://localhost:8080 the only events that trigger are CLOSE and ERROR. I cannot get the client to connect. I must be missing something very simple. Do I need to set up my nodejs folder in IIS for example and then use that as the URL?
Just to reiterate, the websocket server is running fine, I just don't know what URL to use to connect to it from the client.
EDIT: The websocket server reports the following error.
Specified protocol was not requested by the client.
I think I have got it working by doing the following.
var websocket = new WebSocket("ws://localhost:8080/","echo-protocol");
The problem being that I needed to specify a protocol. At least now I get the onopen event. ...if nothing much else
I was seeing the same error, the entire web server goes down. Adding the protocol fixes it but leaves me wondering why it was implemented this way. I mean, one bad request should not bring down your server.
You definitely have to encase it a try/catch, but the example code provided here https://www.npmjs.com/package/websocket (2019-08-07) does not. This issue can be easily avoided.
I just wanted to share a crazy issue that I had. I was able to connect to a websocket of an old version of a 3rd party app in one computer, but not to a newer version of the app in another.
Moreever, even in new computer with the new version of the app, The app was able to connect to the websocket, but no matter what I did, when I tried to connect with my own code, I kept getting the error message that the websocket connection failed
Long story short, They changed an apache configuration that allowed connecting to the websocket via a proxy.
In the old version, apache config was:
ProxyPass /socket/ ws://localhost:33015/ retry=10
ProxyPass /socket ws://localhost:33015/ retry=10
In the new version, apache config was changed to:
ProxyPass /socket/ ws://localhost:33015/ retry=10
By bad luck, I was trying to connect to ws://localhost/socket and not to ws://localhost/socket/. As a result, proxy was not found, and connection returned an error.
Moral of the story: Make sure that you are trying to connect to a websocket url that exists.
For me, the solution was to change the URL from ws:// to wss://. This is because the server I was connecting to had updated its security, and now only accepted wss.

NodeJS - What does "socket hang up" actually mean?

I'm building a web scraper with Node and Cheerio, and for a certain website I'm getting the following error (it only happens on this one website, no others that I try to scrape.
It happens at a different location every time, so sometimes it's url x that throws the error, other times url x is fine and it's a different url entirely:
Error!: Error: socket hang up using [insert random URL, it's different every time]
Error: socket hang up
at createHangUpError (http.js:1445:15)
at Socket.socketOnEnd [as onend] (http.js:1541:23)
at Socket.g (events.js:175:14)
at Socket.EventEmitter.emit (events.js:117:20)
at _stream_readable.js:910:16
at process._tickCallback (node.js:415:13)
This is very tricky to debug, I don't really know where to start. To begin, what IS a socket hang up error? Is it a 404 error or similar? Or does it just mean that the server refused a connection?
I can't find an explanation of this anywhere!
EDIT: Here's a sample of code that is (sometimes) returning errors:
function scrapeNexts(url, oncomplete) {
request(url, function(err, resp, body) {
if (err) {
console.log("Uh-oh, ScrapeNexts Error!: " + err + " using " + url);
errors.nexts.push(url);
}
$ = cheerio.load(body);
// do stuff with the '$' cheerio content here
});
}
There is no direct call to close the connection, but I'm using Node Request which (as far as I can tell) uses http.get so this is not required, correct me if I'm wrong!
EDIT 2: Here's an actual, in-use bit of code that is causing errors. prodURL and other variables are mostly jquery selectors that are defined earlier. This uses the async library for Node.
function scrapeNexts(url, oncomplete) {
request(url, function (err, resp, body) {
if (err) {
console.log("Uh-oh, ScrapeNexts Error!: " + err + " using " + url);
errors.nexts.push(url);
}
async.series([
function (callback) {
$ = cheerio.load(body);
callback();
},
function (callback) {
$(prodURL).each(function () {
var theHref = $(this).attr('href');
urls.push(baseURL + theHref);
});
var next = $(next_select).first().attr('href');
oncomplete(next);
}
]);
});
}
There are two cases when socket hang up gets thrown:
When you are a client
When you, as a client, send a request to a remote server, and receive no timely response. Your socket is ended which throws this error. You should catch this error and decide how to handle it: whether retry the request, queue it for later, etc.
When you are a server/proxy
When you, as a server, perhaps a proxy server, receive a request from a client, then start acting upon it (or relay the request to the upstream server), and before you have prepared the response, the client decides to cancel/abort the request.
This stack trace shows what happens when a client cancels the request.
Trace: { [Error: socket hang up] code: 'ECONNRESET' }
at ClientRequest.proxyError (your_server_code_error_handler.js:137:15)
at ClientRequest.emit (events.js:117:20)
at Socket.socketCloseListener (http.js:1526:9)
at Socket.emit (events.js:95:17)
at TCP.close (net.js:465:12)
Line http.js:1526:9points to the same socketCloseListener mentioned by #Blender, particularly:
// This socket error fired before we started to
// receive a response. The error needs to
// fire on the request.
req.emit('error', createHangUpError());
...
function createHangUpError() {
var error = new Error('socket hang up');
error.code = 'ECONNRESET';
return error;
}
This is a typical case if the client is a user in the browser. The request to load some resource/page takes long, and users simply refresh the page. Such action causes the previous request to get aborted which on your server side throws this error.
Since this error is caused by the wish of a client, they don't expect to receive any error message. So, no need to consider this error as critical. Just ignore it. This is encouraged by the fact that on such error the res socket that your client listened to is, though still writable, destroyed.
console.log(res.socket.destroyed); //true
So, no point to send anything, except explicitly closing the response object:
res.end();
However, what you should do for sure if you are a proxy server which has already relayed the request to the upstream, is to abort your internal request to the upstream, indicating your lack of interest in the response, which in turn will tell the upstream server to, perhaps, stop an expensive operation.
Take a look at the source:
function socketCloseListener() {
var socket = this;
var parser = socket.parser;
var req = socket._httpMessage;
debug('HTTP socket close');
req.emit('close');
if (req.res && req.res.readable) {
// Socket closed before we emitted 'end' below.
req.res.emit('aborted');
var res = req.res;
res.on('end', function() {
res.emit('close');
});
res.push(null);
} else if (!req.res && !req._hadError) {
// This socket error fired before we started to
// receive a response. The error needs to
// fire on the request.
req.emit('error', createHangUpError());
req._hadError = true;
}
}
The message is emitted when the server never sends a response.
One case worth mentioning: when connecting from Node.js to Node.js using Express, I get "socket hang up" if I don't prefix the requested URL path with "/".
below is a simple example where I got the same error when I missed to add the commented code in below example. Uncommenting the code req.end() will resolve this issue.
var fs = require("fs");
var https = require("https");
var options = {
host: "en.wikipedia.org",
path: "/wiki/George_Washington",
port: 443,
method: "GET"
};
var req = https.request(options, function (res) {
console.log(res.statusCode);
});
// req.end();
I used require('http') to consume https service and it showed "socket hang up".
Then I changed require('http') to require('https') instead, and it is working.
Expanding on Blender's answer, this happens in a number of situations. The most common ones I run into are:
The server crashed.
The server refused your connection, most likely blocked by User-Agent.
socketCloseListener, as outlined in Blender's answer, is not the only place that hangup errors are created.
For example, found here:
function socketOnEnd() {
var socket = this;
var req = this._httpMessage;
var parser = this.parser;
if (!req.res) {
// If we don't have a response then we know that the socket
// ended prematurely and we need to emit an error on the request.
req.emit('error', createHangUpError());
req._hadError = true;
}
if (parser) {
parser.finish();
freeParser(parser, req);
}
socket.destroy();
}
You could try curl with the headers and such that are being sent out from Node and see if you get a response there. If you don't get a response with curl, but you do get a response in your browser, then your User-Agent header is most likely being blocked.
Another case worth mentioning (for Linux and OS X) is that if you use a library like https for performing the requests, or if you pass https://... as a URL of the locally served instance, you will be using port 443 which is a reserved private port and you might be ending up in Socket hang up or ECONNREFUSED errors.
Instead, use port 3000, f.e., and do an http request.
For request module users
Timeouts
There are two main types of timeouts: connection timeouts and read timeouts. A connect timeout occurs if the timeout is hit while your client is attempting to establish a connection to a remote machine (corresponding to the connect() call on the socket). A read timeout occurs any time the server is too slow to send back a part of the response.
Note that connection timeouts emit an ETIMEDOUT error, and read timeouts emit an ECONNRESET error.
This caused me issues, as I was doing everything listed here, but was still getting errors thrown. It turns out that calling req.abort() actually throws an error, with a code of ECONNRESET, so you actually have to catch that in your error handler.
req.on('error', function(err) {
if (err.code === "ECONNRESET") {
console.log("Timeout occurs");
return;
}
//handle normal errors
});
I had the same problem while using Nano library to connect to Couch DB. I tried to fine tune connection pooling with use of keepaliveagent library and it kept failing with socket hang up message.
var KeepAliveAgent = require('agentkeepalive');
var myagent = new KeepAliveAgent({
maxSockets: 10,
maxKeepAliveRequests: 0,
maxKeepAliveTime: 240000
});
nano = new Nano({
url : uri,
requestDefaults : {
agent : myagent
}
});
After some struggling I was able to nail the problem - as it came out it was very, very simple mistake. I was connecting to the database via HTTPS protocol, but I kept passing to my nano object a keepalive agent created as the examples for use of this library show (they rely on some defaults that use http).
One simple change to use HttpsAgent did the trick:
var KeepAliveAgent = require('agentkeepalive').HttpsAgent;
I think "socket hang up" is a fairly general error indicating that the connection has been terminated from the server end. In other words, the sockets being used to maintain the connection between the client and the server have been disconnected. (While I'm sure many of the points mentioned above are helpful to various people, I think this is the more general answer.)
In my case, I was sending a request with a payload in excess of 20K. This was rejected by the server. I verified this by removing text and retrying until the request succeeded. After determining the maximum acceptable length, I verified that adding a single character caused the error to manifest. I also confirmed that the client wasn't the issue by sending the same request from a Python app and from Postman. So anyway, I'm confident that, in my case, the length of the payload was my specific problem.
Once again, the source of the problem is anecdotal. The general problem is "Server Says No".
I had the same problem during request to some server. In my case, setting any value to User-Agent in headers in request options helped me.
const httpRequestOptions = {
hostname: 'site.address.com',
headers: {
'User-Agent': 'Chrome/59.0.3071.115'
}
};
It's not a general case and depends on server settings.
This error also can happen when working with http.request, probably your request is not finished yet.
Example:
const req = https.request(options, res => {})
And you always need to add this line: req.end()
With this function we will order to finish sending request.
As in documentation is said:
With http.request() one must always call req.end() to signify the end of the request - even if there is no data being written to the request body.
Also reason can be because of using app instance of express instead of server from const server = http.createServer(app) while creating server socket .
Wrong
const express = require('express');
const http = require('http');
const WebSocket = require('ws');
const app = express();
app.use(function (req, res) {
res.send({ msg: "hello" });
});
const wss = new WebSocket.Server({ server: app }); // will throw error while connecting from client socket
app.listen(8080, function listening() {
console.log('Listening on %d', server.address().port);
});
Correct
const express = require('express');
const http = require('http');
const WebSocket = require('ws');
const app = express();
app.use(function (req, res) {
res.send({ msg: "hello" });
});
const server = http.createServer(app);
const wss = new WebSocket.Server({ server });
server.listen(8080, function listening() {
console.log('Listening on %d', server.address().port);
});
it's been a long time but another case is when performing requests which takes a long time on the server side (more then 2 minutes which is the default for express) and the timeout parameter was not configured in the server side. In my case I was doing client->server->server request (Node.js express) and I should set the timeout parameter on each request router on the server and on the client.
So in both servers I needed to set the request timeout by using
req.setTimeout([your needed timeout])
on the router.
I do both web (node) and Android development, and open Android Studio device simulator and docker together, both of them use port 8601, it complained socket hang up error, after close Android Studio device simulator and it works well in node side. Don’t use Android Studio device simulator and docker together.
There seems to be one additional case here, which is Electron not being a fan of the "localhost" domain name. In my case I needed to change this:
const backendApiHostUrl = "http://localhost:3000";
to this:
const backendApiHostUrl = "http://127.0.0.1:3000";
After that the problem just went away.
This means that DNS resolution (local or remote) might be causing some problems too.
I got a similar error when using CouchDB on OCP cluster.
const cloudantSessionStore = sessionStore.createSessionStore(
{
type: 'couchdb',
host: 'https://' + credentials['host'],
port: credentials['port'],
dbName: 'sessions',
options: {
auth: {
username: credentials['username'],
password: credentials['password']
},
cache: false
}
}
Which should be "http", not "https", to connect with my CouchDB instance. Hope it could be helpful for anyone who is faced with similar issue.
In my case, it was because a application/json response was badly formatted (contains a stack trace). The response was never send to the server.
That was very tricky to debug because, there were no log. This thread helps me a lot to understand what happens.
In case you're using node-http-proxy, please be aware to this issue, which will result a socket hang-up error : https://github.com/nodejitsu/node-http-proxy/issues/180.
For resolution, also in this link, simply move declaring the API route (for proxying) within express routes before express.bodyParser().
Ran into this issue yesterday running my web application and node.js server through IntelliJ IDEA 2016.3.6. All I had to do was clear my cookies and cache in my Chrome browser.
If you are experiencing this error over a https connection and it's happening instantly it could be a problem setting up the SSL connection.
For me it was this issue https://github.com/nodejs/node/issues/9845 but for you it could be something else. If it is a problem with the ssl then you should be able to reproduce it with the nodejs tls/ssl package just trying to connect to the domain
I think worth noting...
I was creating tests for Google APIs. I was intercepting the request with a makeshift server, then forwarding those to the real api. I was attempting to just pass along the headers in the request, but a few headers were causing a problem with express on the other end.
Namely, I had to delete connection, accept, and content-length headers before using the request module to forward along.
let headers = Object.assign({}, req.headers);
delete headers['connection']
delete headers['accept']
delete headers['content-length']
res.end() // We don't need the incoming connection anymore
request({
method: 'post',
body: req.body,
headers: headers,
json: true,
url: `http://myapi/${req.url}`
}, (err, _res, body)=>{
if(err) return done(err);
// Test my api response here as if Google sent it.
})
I my case it's was not an error, but expected behavior for chrome browser. Chrome keeps tls connection alive (for speed i think), but node.js server stop it after 2 min and you get an error.
If you try GET request using edge browser, there will be no error at all.
If you will close chrome window - you will get error right away.
So what to do?
1)You can filter this errors, because they are not really errors.
2)Maybe there is a better solution :)
After a long debug into node js code, mongodb connection string, checking CORS etc, For me just switching to a different port number server.listen(port); made it work, into postman, try that too. No changes to proxy settings just the defaults.
I was using nano, and it took me a long time to figure out this error. My problem was I was using the wrong port. I had port 5948 instead of 5984.
var nano = require('nano')('http://localhost:5984');
var db = nano.use('address');
var app = express();
Might be your server or Socket connection crashes unexpectedly.
I had this error when running two applications on the same port by mistake.
I had a next.js app and another one in nest.js, running both on port 8080, when I looked at the .env files I realized that they had the same port, so I changed the one from nest.js to 3000 and everything worked.
I'm not saying that this is the reason for the error but it's a possibility.
Your problem might also come from an attempt to connect to an HTTP URL while your service is only published on HTTPS...
Definitely a time-consuming mistake!
Got "[GET] localhost:4200, Socket hang up" during Azure Static Web App (SWA) Emulator for Angular app.
Solution is to remove this from angular.json:
"headers": {"cross-origin-opener-policy": "same-origin-allow-popups"}

some questions from a node.js newbie

i have just started learning node and i am using node-v0.4.11 on Fedora 12. It installed without any errors and i am able to run some basic programs but there are some things i cant figure out
If i create a server at a port and then if i stop node using Ctrl+C
i cannot use that port again for starting a server without restarting
the system.
my code looks like this
var port=8080;
var count=0;
var http=require('http');
var server = http.createServer(function(req, res) {
count++;
console.log('request no '+count+' received');
res.writeHead(200);
res.end('you are at port '+port);
});
server.listen(port);
console.log('server started at port '+port);
Now when i save the file and execute it the server starts. But when i stop the server from the shell , i cannot start the server again at the port i started before(in this case port 8080).This is bad because every time i have to make changes in that file i have to change the port number too.Can i stop this behavior?
EDIT:
This is the error that i get when i try to start the server at the same port again
Server started at 8080
node.js:203
throw e; // process.nextTick error, or 'error' event on first tick
^
Error: listen EADDRINUSE
at errnoException (net_uv.js:557:11)
at Array.<anonymous> (net_uv.js:632:28)
at EventEmitter._tickCallback (node.js:195:26)
i saw the process list after i terminated node using Ctrl+C and i found node was still running. So i killed it and checked the process list again to make sure it was dead and it was(i could not see it in the process list). Now i again tried to start the server at the same port but i got the same error as above.And once i stop the server and make request from the browser the request hangs up for ever(it keeps on waiting).
My next problem is that in the above when the server starts and i make
the first request count is incremented 3 times and i can see 3
messages at the console. This is just for the first request,if i make
more requests count is just incremented once. Whats wrong?
this problem is solved
My next problem is that if i change res.writeHead(200); to
res.writeHead(404); or any other valid status code like 300 node
gives error at the command line but these are valid status codes and
the server should start and respond to each request according the
status code like Not found for 404. What am i doing wrong?
this problem is solved
I am not able to use Firebug's 'Net' tab to monitor requests when i
send requests to the server created by Node. Is there a way to do so?
Thanks for bearing.
i cannot start the server again at the port i started before
You should not be seeing this behavior, and I cannot reproduce it. Do you get an error message when you try to start the server again? What is it? Once you've stopped the server, do you see any node processes in your process list? If so, can you start your server after you kill them?
count is incremented 3 times and i can see 3 messages at the console
Your browser is sending multiple requests. For example, in Chrome, you might get (1) a pre-fetch request (where Chrome downloads the page it thinks you want), (2) the actual page request, and (3) a request for favicon.ico; your Node app is listening for all requests, not just requests to the / URL. After the initial request, the browser caches the favicon, etc. and doesn't need to request them again.
Try adding console.log(req.url); to your callback and see what URLs the browser is asking for.
any other valid status code like 300 node gives error at the command line
I can't reproduce this problem. What error are you receiving?
I am not able to use Firebug's 'Net' tab to monitor requests when i send requests to the server created by Node
I'm also not able to reproduce this. Firebug and other client-side debugging tools don't know or care what technology is running on the server; it just speaks HTTP.

Resources