Newbie Question

[Ray Jender]

So, for all of the example and demo code I have seen, they always include doing "node file.js" and then it echos back "Listening at: http://localhost:8080"  or similar.
Which implies I have to browse to port 8080 to use the app.

My question is how does this work in production?   I have never had to browse to a website using a port number?   I'm confused?
How can I simply browse to a URL and not include a port number?

Thanks,

Ray

[ManuelPineda]

If you don't write the port number, the port 80 is taken by default.

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/c1887b7f-7a7d-4eb7-b94e-c6d9bcd5bb6c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Aria Stewart]

So -- there's some interesting details to that!

Each service on the Internet has a port assigned to it in the specification for it. http is port 80, ssh is 22, https is 443, xmpp is 5222 (and a few others, because it's complicated), pop3 is 110 and imap is 143. If the service is running on its normal port, things don't usually need to know the port because it can just assume the usual one. In http URLs, this lets us leave the port number out -- http://example.org/ and http://example.org:80/ in theory point to the same resource. (some systems treat them as 'different' when comparing, but they access the same resources.)

Now if you're NOT on the default port, you have to specify -- so Express apps in particular suggest you connect to http://localhost:yourport/. This is actually just a hint -- usually they listen to more than localhost, and the report back for the URL is actually not very robust, but it works enough to get people off the ground.

If you run your app on port 80, you won't need that.

However!

Unix systems restrict ports under 1024 as reserved for the system -- a simple enough restriction to keep a user from starting up something in place of a system service at startup time, in the era of shared systems. That means you have to run something as root to bind port 80, unless you use special tools. There's one called authbind that lets you bind a privileged port (found most commonly on Debian-derived Linuxes), one can call process.setuid and process.setgid to relinquish root privilege after binding (a common tactic in classic unix systems), though there's some fiddly details there that could leave you exposed if someone manages to inject executable code into what you're running. And finally, one can proxy from a 'trusted' system daemon to your app on some arbitrary port -- nginx is a popular choice for this, as are haproxy, stunnel and others.

Hope this helps

Aria

[Grant MacDonald]

Hi Ray.  I use NGINX on LINUX servers and create a Reverse Proxy.  On Windows Servers I create the Reverse Proxy in IIS (I'm sure NGINX would work in Windows as well.)

All the best,

Grant.

[zladuric]

We set the port to whatever we want, but it's a common security and usage practice to not use "low ports" (lower then 1024) for app servers. In fact, in most operating systems, if you run the app server as a non-system user, you _cannot_ bind to such port.

The usual practice for Node.js (or, say, Tomcat, or Websphere or RoR or any other app servers) to be bound to some high port (above 1024) and then let nginx, apache, IIS or something else serve the port 80, and proxy over requests to the app server.

That way on one host you can even run multiple app servers with one web server.

Nothing would stop you to run as, say, root on Linux or a Mac, and bind the Node.js app to port 80, but then  your app has root privileges, and if your code (or some of the modules you use) is buggy or has security problems, your app would be a risk to the whole system.

Zlatko

[Ray Jender]

But how does that alleviate the issue of haveing to browse to IP:Port?  I'm not liking that in a production environment.  Or am I missing something?

[Grant MacDonald]

Hi Ray.  If the node.js was running on realserver.com:5000.  For the Reverse Proxy I first set up a DNS alias for the server (ie. myapp.com to realserver.com.)  The reverse proxy in NGINX would look something like this:

server {

  listen 80;

  server_name myapp.com;

  location / {

      proxy_pass http://localhost:5000/;

  }
}

When the user browses to myapp.com (no port #) it gets redirected to realserver.com>localhost:5000.

This is 1 way to eliminate the user to enter a port #. 

All the best, 

Grant.

[Peter Rust]

Ray,

When you browse to http://www.google.com/, it is actually going to http://www.google.com:80/ -- the port 80 is the default for http, it's implied if you don't specify a number.

So all you need to do is serve on port 80 and then the end user won't need to type a port number.

A lot of times on production setups there is a front-door kind of server that handles traffic coming in on port 80 (or 443, which is the default for 443) and figures out what other app or server needs to handle that particular traffic (based on the subdomain or the path or whatnot) and proxies the request to the port that the appropriate server is running on. That way you can have different servers running on different ports behind the scenes, but all traffic interfacing with the public going over port 80.

But if you have a simple setup, you can just serve on port 80 and have everything go through your one server.

For a lot of hosting setups (like Nodejitsu) you can serve on whatever port you want and their load balancer redirects port 80 traffic to your process.

-- peter

[Ryan Schmidt]

nginx, apache, IIS or whatever other web server you use would be configured using the standard web port, 80, so that the user does not need to specify the port. Then, behind the scenes, that web server would talk with your node app, running on whatever other higher port number it wants to use, and the user will never need to know.

[Gustavo Machado]

Ray, a few clarifications on Grant's email. By setting things up with NGINX, it now becomes your point of entry for your user's traffic (hence the name "reverse-proxy").

Cheers!

Gus

On Sun, Jun 21, 2015 at 7:56 AM, Grant MacDonald <minevill...@gmail.com> wrote:

Hi Ray.  If the node.js was running on realserver.com:5000.  For the Reverse Proxy I first set up a DNS alias for the server (ie. myapp.com to realserver.com.)  The reverse proxy in NGINX would look something like this:

The DNS alias does not necessarily map to the "realserver", but it should map to the NGINX server (which could be same host).

 

server {

  listen 80;

  server_name myapp.com;

  location / {

      proxy_pass http://localhost:5000/;

  }
}

It can proxy to "localhost" or any other location, usually an internal (non-reachable from internet) host.

 

When the user browses to myapp.com (no port #) it gets redirected to realserver.com>localhost:5000.

It get's "proxy'd", not redirected. Proxying can be transparent for the browser, while redirects are literally handled by browsers.

 

 

This is 1 way to eliminate the user to enter a port #. 

All the best, 

Grant.

On Saturday, June 20, 2015 at 11:36:33 PM UTC-3, Ray Jender wrote:

But how does that alleviate the issue of haveing to browse to IP:Port?  I'm not liking that in a production environment.  Or am I missing something?

On Saturday, June 20, 2015 at 10:36:28 AM UTC-4, zladuric wrote:

We set the port to whatever we want, but it's a common security and usage practice to not use "low ports" (lower then 1024) for app servers. In fact, in most operating systems, if you run the app server as a non-system user, you _cannot_ bind to such port.

The usual practice for Node.js (or, say, Tomcat, or Websphere or RoR or any other app servers) to be bound to some high port (above 1024) and then let nginx, apache, IIS or something else serve the port 80, and proxy over requests to the app server.

That way on one host you can even run multiple app servers with one web server.

Nothing would stop you to run as, say, root on Linux or a Mac, and bind the Node.js app to port 80, but then  your app has root privileges, and if your code (or some of the modules you use) is buggy or has security problems, your app would be a risk to the whole system.

Zlatko

On Saturday, June 20, 2015 at 3:43:51 AM UTC+2, Ray Jender wrote:

So, for all of the example and demo code I have seen, they always include doing "node file.js" and then it echos back "Listening at: http://localhost:8080"  or similar.
Which implies I have to browse to port 8080 to use the app.

My question is how does this work in production?   I have never had to browse to a website using a port number?   I'm confused?
How can I simply browse to a URL and not include a port number?

Thanks,

Ray

--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/86cd3a7e-75ac-43de-82f0-09ec0350d192%40googlegroups.com.