Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
In PHP, we have Apache (or Nginx) as the HTTP server. They are also the de-facto standard set up for PHP web development.
In Rust nearly all examples on the web are to run its own HTTP server (or "hyper" library) by "Cargo run" command and then go to localhost in a browser to see the result. It seems nobody would deploy it on Apache/Nginx.
Why are Rust programs not deployed in the existing HTTP servers which provide so many useful and mature features (e.g. VirtualHost, Alias, SSL, mod_rewrite etc.)?
Also, what're the benefits of using this web server over Apache/Nginx?
In a production environment, do you also use hyper library as the web server for Rust?
The common approach when writing a web application in something other than PHP is to use either Apache or NGINX as the public-facing server. You then set up a virtual host in either Apache or NGINX to function as a remote proxy which forwards all connections to your web application (Rust, Golang, Python, Node.js, etc...) which is, itself, running its own server bound to a non-80 port on localhost.
For a (rough) visual example:
+++++++++++++++++++++++ SERVER +++++++++++++++++++++++++++++++++++
+ [Web Application (bound to localhost:8080)] +
+ /|\ +
+ | reverse proxy connection +
+ \|/ +
+ [NGINX (bound to remote_address::80 and remote_address:443)] +
+++++++++++++++++++++++++/|\+++++++++++/|\++++++++++++++++++++++++
| |
\|/ \|/
++++++++++++ ++++++++++++
+ CLIENT + + CLIENT +
++++++++++++ ++++++++++++
This approach is (generally) more secure, allows you to easily use the features of a mature web server like you are saying (e.g. SSL, load balancing, etc.), and allows you to focus on writing a robust web application rather than on writing a robust web server.
Take a look at this article for documentation on how to set up NGINX as a reverse proxy. Although Apache is just as capable, NGINX tends to be the web server of choice when creating a web application and stack like this due to its speed and the fact that it is relatively lightweight.
For what it is worth, the difference between this architecture and what, for example, PHP and Apache look like together is, simply put, that PHP runs as an "extension module" to Apache rather than as an "external component". Actually, when you use PHP with NGINX, you will have to set it up in a very similar way as described in this post.
Related
This is my first time posting on Stack Overflow.
I'm trying an automation personal project.
My question is: How do I serve the completed web servers from the GitHub repository using NGINX or Apache?
For example, if I made a change to the code. I want to be directly served to the internet by using NGINX.
Any suggestions will do.
I would like to setup mod_security as a stand alone instance protecting Tomcat instances against web application attacks. Would anyone know the pros and cons of doing this via installing mod_security as an Apache module versus installing mod_security on a reverse proxy? Has anyone implemented mod_security in either of these fashions? And if so is one preferred over the other?
There's really no difference in your two options. What non reverse proxy would you install the module on to protect Tomcat?
The question doesn't really make sense as they are both the same to you.
If you already have an Apache server, then you install ModSecurity in one of two ways:
In embedded mode by installing ModSecurity as module in the existing Apache instance you already have. The advantages are that you won't have to set up a separate Apache instance, and that the ModSecurity will have access to the environment that Apache runs under (so can see environment variables for example or log to same log files).
In a reverse proxy mode. This involves setting up a separate Apache instance, with ModSecurity on it only, and funnel all requests through it, before sending on the requests to your normal Apache. The advantages here are a dedicated web server just for ModSecurity, so you will not share resources with your existing version of Apache, if it is already resource hungry. Disadvantages are that it doubles your infrastructure and the complications that brings.
Personally I prefer option 1.
However, as you want to set up a dedicated web server in front of TomCat, the two options are identical for you. The new instance of Apache (or Nginx) that you set up will be running it in embedded mode and will act as a reverse proxy to your Tomcat server.
Personally I always think it's best to run a dedicated web server like Apache in front of any app server like Tomcat - especially on a public facing website. Granted Tomcat does include a pretty good web server (called Coyote), which may serve most of your web server needs, but a dedicated web server like Apache is more geared towards serving static content and contains other features for performance and security which make it a better end point server (including the ability to run ModSecurity for example!).
And just in case there is any confusion, Apache is actually short for Apache HTTP Server, and is sometimes called Apache httpd after the process that it runs. It is Apache's most popular bit of software hence why the name gets shortened, but Apache actually have lots of bits of software (including Apache Tomcat - usually shortened just to Tomcat).
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why do we need apache under Node.js express web framework?
I wonder why I should install a server such as Nginx or Apache with Node.js. I used to think that the server can help me to handle cache control or something more. But I found out that the Connect static middleware already does it, right?
If you don't know why you need Nginx or Apache on top of Node.js, then you don't need it.
Nginx does a few things faster (and in some cases easier to configure) than Node.js: proxying, url rewriting, http caching, redirection, static file serving, and load balancing.
If you experience that your Node.js code for any of these roles are growing complex, or turn out to be performance bottlenecks, it's worth investigating. Until then, no need to bother.
Using stable and solid web server software as front end can bring several advantages. For example, you can use Nginx for load balancing. Furthermore, security risks can be reduced by not presenting your application server directly to the internet.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm using Apache ProxyPass to pass some requests from my server (1) to another (2). This works fine for most requests, but when server 2 processes a POST request and sends a redirect header, this is passed right through to the client, who then applies the redirect on server 1 and thus gets a 404.
So what I'd like is that server 1 (the server with the ProxyPass) follows redirects on server 2 and passes the final page back to the client.
I'm sure this must be a very common scenario, but I can't seem to find the solution. I'm imagining something like a "follow_redirects" flag, similar as you would apply to a curl client, but I haven't found anything like that. Maybe what I'm trying to do isn't the purpose of ProxyPass?
Could someone point me in the right direction here?
Thanks,
Chris
Check out the ProxyPassReverse directive. With this set Apache can intercept redirects and rewrite them so the client doesn't leave the proxy. This will not process redirects on the proxy, but it will at least make the client send the redirected request back to your server instead of leaving you.
I found the Apache Traffic Server, which is a reverse-proxy made by Yahoo and given to the Apache foundation.
From this documentation:
Origin servers often send redirect responses back to browsers
redirecting them to different pages. For example, if an origin server
is overloaded, then it might redirect browsers to a less loaded
server. Origin servers also redirect when web pages that have moved to
different locations. When Traffic Server is configured as a reverse
proxy, it must readdress redirects from origin servers so that
browsers are redirected to Traffic Server and not to another origin
server.
I haven't tried this yet, but there are packages for Debian, Ubuntu and CentOS.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What is the difference in terms of functionality between the Apache HTTP Server and Apache Tomcat?
I know that Tomcat is written in Java and the HTTP Server is in C, but other than that I do not really know how they are distinguished. Do they have different functionality?
Apache Tomcat is used to deploy your Java Servlets and JSPs. So in your Java project you can build your WAR (short for Web ARchive) file, and just drop it in the deploy directory in Tomcat.
So basically Apache is an HTTP Server, serving HTTP. Tomcat is a Servlet and JSP Server serving Java technologies.
Tomcat includes Catalina, which is a servlet container. A servlet, at the end, is a Java class. JSP files (which are similar to PHP, and older ASP files) are generated into Java code (HttpServlet), which is then compiled to .class files by the server and executed by the Java virtual machine.
In addition to the fine answers above, I think it should be said that Tomcat has it's own HTTP server built into it, and is fully functional at serving static content too. Depending on your java virtual machine configuration it can actually outperform going through traditional connectors in apache such as mod_proxy and mod_jk.
That said a fully optimized Tomcat server should serve static files fast and if you have Java servlets, JSPs and ColdFusion files in addition to static content you may find tomcat does an excellent job by itself.
Apache is a general-purpose http server, which supports a number of advanced options that Tomcat doesn't.
Although Tomcat can be used as a general purpose http server, you can also set up Apache and Tomcat to work together with Apache serving static content and forwarding the requests for dynamic content to Tomcat.
Tomcat is primarily an application server, which serves requests to custom-built Java servlets or JSP files on your server. It is usually used in conjunction with the Apache HTTP server (at least in my experience). Use it to manually process incoming requests.
The HTTP server, by itself, is best for serving up static content... html files, images, etc.
an apache server is an http server which can serve any simple http requests, where tomcat server is actually a servlet container which can serve java servlet requests.
Web server [apache] process web client (web browsers) requests and forwards it to servlet container [tomcat] and container process the requests and sends response which gets forwarded by web server to the web client [browser].
Also you can check this link for more clarification:-
https://sites.google.com/site/sureshdevang/servlet-architecture
Also check this answer for further researching :-
https://softwareengineering.stackexchange.com/a/221092
If you are using java technology(Servlet/JSP) for making web application you will probably use Apache Tomcat.
However, if you are using other technologies like Perl, PHP or ruby, its better(easier) to use Apache HTTP Server.
Well, Apache is HTTP webserver, where as Tomcat is also webserver for Servlets and JSP.
Moreover Apache is preferred over Apache Tomcat in real time
Apache is an HTTP web server which serve as HTTP.
Apache Tomcat is a java servlet container. It features same as web server but is customized to execute java servlet and JSP pages.