This was a question in a recent interview I took. I answered, that to my awareness there is no such way. But I am not sure.
Is there a way to stop Apache web server from answering an HTTP request?
I used PHP as the language of choice, if it makes a difference.
To better understand this answer you need to understand the networking "OSI 7 Layer Networking Model". (More details here: https://en.wikipedia.org/wiki/OSI_model )
What this demonstrates is that Apache will "handle" a request before PHP code even begins to execute. (Apache operates at layers 5,6, and 7, where PHP Typically Operates on top of apache).
Therefore PHP code is going to be ill equipped to "stop" apache from Answering an HTTP request. Instead, you will want to look at blocking access entirely (A Firewall [Either hardware of software based], operating at layer 3/4) or you will need apache to have logic to not handle the request.
This is actually more of a security question, than a programming question. Typically for this use case you would want an apache module to make a determination inside apache about handling a request. A few good modules for this are: mod_evasive, mod_security
Mod_Evasive:
https://www.digitalocean.com/community/tutorials/how-to-protect-against-dos-and-ddos-with-mod_evasive-for-apache-on-centos-7
Mod_Security
https://geekflare.com/apache-web-server-hardening-security/#6-Mod-Security
Please let me know if you have any questions, Thanks!
Related
I am choosing a better web server for big SPA application with dozens of JS and css files. With HTTP/2 we are now able to not merge them into two big files (3 MB for JS), that take pretty long time to load when on slow connection. But which server is better for the new HTTP/2 paradigm?
Nginx was designed to solve http/1 problems, and it's advantage was better serving numerous connections, with HTTP/2 there is only one connection for all the files, so the feature seems redundant now. What do you think, what can you advise me?
That's a very subjective question, and probably not a good fit for StackOverflow so imagine this will get closed. But here's my two cents...
Full disclosure: I primarily use Apache.
For a start let's address one of your incorrect points: Nginx wasn't designed to solve HTTP/1 problems. Nginx was designed to solve some of the scalability problems of previous web servers by being based on an asynchronous, event-driven model. Under HTTP/2 there should be less connections per client, which you could argue makes scalability less of an issue as each client uses only 1/6th of the resources they did previously - but that's probably a little simplistic. Apache has an event-driven MPM module for years now too (though often not turned on by default in case of any thread unsafe PHP applications - but this would also be a problem with Nginx!). This brings them more back in line, though there's still a lot of debate about this and many say Nginx is still faster. In my experience, unless you are dealing with truly huge volumes (in which case you should be looking at CDNs, load-balancers and cache accelerators), few will ever notice the difference between Nginx and Apache. This is especially true when downstream applications and systems come into play - a slow PHP application will quickly negate any performance or scalability issues at the web server level.
Anyway, back to your main question:
For HTTP/2 support, my choice would be Apache over Nginx. It has had better HTTP/2 support for some time. Nginx only added HTTP/2 Push support in early 2018 for example, whereas Apache has had that for a number of years now. Apache also supports a PushDiary (based on the now-abandon Cache-Digests proposal) to prevent pushing resources that have already been sent, supports 103 Early Hints for pushing early, and push prioritisation options. Moving on from HTTP/2 push, Apache also supports using HTTP/2 in proxy mode (though it's still marked as experimental and the usefulness of this is questionable at the moment), and HTTP/2 over HTTP (h2c - though again usefulness is questionable since browsers do not support this). I also find the main developer of the Apache HTTP/2 implementation very responsive on the GitHub page for the mod_http2 module (included as part of core Apache since 2.4.18 and no longer marked as "experimental" since 2.4.26).
On the flip side, I understand that Cloudflare uses a customised Nginx based web server, and they have HTTP/2 push for over a year now (it was them that backported this implementation to Nginx). So, given Cloudflare's scale, that speaks volumes to the implementation of that though not sure how customised it is from the core Nginx code.
There is also a HTTP/2 conformance Testing tool available and when I ran this against some common HTTP/2 servers (for a book I wrote on the subject btw) I got the following results which clearly shows Apache as the most compliant with the spec:
Now to be fair, most of the causes of errors are in not responding correctly to bad requests, that in a perfect world should never be sent anyway so aren’t that important. But still, we don’t live in a perfect world, and error checking is an important part of technology so I for one would certainly prefer the more compliant server. Similarly as pointed out in the comments below, the tool and web servers themselves, can be subject to race conditions and other problems which may incorrectly report errors.
Ultimately you are best choosing the implementation you are most comfortable with. The general feel has always been that Nginx is lighter and easier to configure, but on the flip side perhaps isn't as fully featured as Apache because of that. HTTP/2 support seems to continue that theme. If you want to play with upcoming HTTP/2 features then, to me, Apache definitely has the edge at the moment (though nothing to say that won't change in the future). However, for the basic use cases of HTTP/2, they probably can be considered similar. Even HTTP/2 Push is not used much yet, and there are serious concerns it could degrade performance if not used appropriately or due to implementation issues, which is probably why it has not been a priority for Nginx and while they only implemented it later.
Hope this is not something obvious, just want to clarify some things I am not totally sure about. I got this question while watching a tutorial on how to implement caching. There is seems that just adding some global caching variables on the server, will implement caching for all clients. I use PHP with Apache webserver.
I know that a web-server can accept multiple client HTTP requests. My question is what happens on the web server code.
Is the same server code executed each time? Meaning that some global variables are preserved? Or for each new HTTP request, a new instance of the code is created. If yes, are those multiple instances connected or can be made aware of each other in any way?
Bad news is the apache server does not native support for that kind of work. You have to use some intermediate stuff like database to handle this.
However, good news is node.js do that stuff easily in an elegance way :D
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.
For a SaaS running on Node.JS, is a web-server necessary?
If yes, which one and why?
What would be the disadvantages of using just node? It's role is to just handle the CRUD requests and serve JSON back for client to parse the date (like Gmail).
"is a web-server necessary"?
Technically, no. Practically, yes a separate web server is typically used and for good reason.
In this talk by Ryan Dahl in May 2010, at 37'30" he states that he recommends running node.js behind a reverse proxy or web server for "security reasons". To elaborate on that, hardened web servers like nginx or apache have had their TCP stacks evolve for a long time in terms of stability and security. Node.js is not at that same level yet. Thus, since putting node.js behind nginx is easy, doesn't have many negative consequences, and in theory increases the security of your deployment somewhat, it is a good choice. At some point in time, node.js may be deemed officially "ready for live direct Internet connections" but wait for Ryan/Joyent to make some announcement to that effect.
Secondly, binding to sub-1024 ports (like 80 and 443) requires the process to be root. nginx and others automatically handle binding as root and then dropping privileges to a safer user account (www-data or nobody typically). Although node.js has system call wrappers in the process module to drop root privileges with setgid and setuid, AFAIK other than coding this yourself the node community hasn't yet seen a convention emerge for doing this. More on this topic in this discussion.
Thirdly, web servers are good at virtual hosting and in general there are convenient things you can do (URL rewriting and such) that require custom coding in node.js to achieve otherwise.
Fourthly, nginx is great at serving static files. Better than node.js (at least by a little as of right now). Again as time goes forward this point may become less and less relevant, but in my mind a traditional static file web server and a web application server still have distinct roles and purposes.
"If yes, which one and why"?
nginx. Because it has great performance and is simpler to configure than apache.
Which one of these two is most commonly used scenario? I want to use the same scenario in my learning process. thanks.
Don't know about the rest of the industry, but where I work we have Apache HTTPD front-ending for Tomcat.
Any static content is directly provided by HTTPD for performance. Pain in the neck to separate every app out, but there is a noticeable payoff.
Also, HTTPD has some nice code for cookie handling, URL rewriting, clustering and so on.
Only if we determine that there's dynamic, database-bound data to show do we forward to Tomcat, which does an admirable job there.
Has been working well for us for almost a decade. Others too, I would wager.