What is the difference between "A Web Server" and "A Servlet Container"?
In general are all Web Servers Servlet(Web) Containers too or vice versa?
I have been using Apache Tomcat for JSP and Apache for PHP but unable to figure out the exact difference between those two, where exactly lies the difference?
I tried searching previous threads but could not find much.
Thanks! :-)
A Servlet Container is a Web Server that must be able to run Java Servlets.
Web Server, on the other hand, is a broader term including all software running and communicating through HTTP protocol.
Under these definitions:
All Servlet Containers are Web Servers
Not all Web Servers are Servlet Containers. I.E. Apache HTTP Server can not run Java Servlet directly.
HTTP is the Hypertext Transport Protocol. Both Apache and Tomcat will accept HTTP requests.
The difference is that Apache is JUST an HTTP server. It serves up static HTML pages.
Tomcat has an HTTP listener inside it, but in addition to that it has a servlet/JSP engine. It can serve up both static and dynamic HTML pages.
You can use Tomcat without Apache.
Apache cannot handle servlet/JSP requests without having a servlet/JSP engine bolted on top of it
ServletContext is an application specific object, whereas ServletConfig is a Servlet specific object..
ServletConfig object is created as Web container instantiates the respective servlet
Related
I have been trying to develop web pages locally (in Windows 10) and running in my local browser (chrome, vivaldi). Right now I have 3 different ways to run simple servers locally: php's built in server, python's http.server module, and vscode's LiveServer. When I run the php server, I can execute php code properly, as one would expect. But calling php urls using the other two, I get a "Save File" dialog! Where is that coming from? Instead of a simple "not found" I get the dialog. So I have two questions: (1) Why am I getting the save file dialog? (2) Is it possible to process php files using LiveServer or python's http.server module (which I don't expect can ever support php)
if the save dialog is being shown it's cause the server can't interpret php code. You have to check these servers configs to check their integration with PHP (if they they can do that).
Good questions. Erick has answered the 1st one. I'll just elaborate more on it and then answer the 2nd one.
Why do you get save file dialog?
At a high level, a web server is serving files. When serving HTML/CSS/JS files to the browser, life is easy. Your browser understands HTML/CSS/JS and knows how to render it for the user. If your browser was sent unprocessed PHP file (assuming that file was present), the browser won't know what to do with <?php .. ?> tags and such. So, the browser offers the user to download the file. Same thing with a zip file. If you went to http://someurl.com/abc.zip, if the webserver found that file under the root of someurl.com, it'll send it to the browser and the browser will offer the user to download it. There's more to it than just that.
So, how does a web server process PHP files? It depends on the web server, but the common thing is that they need help in processing PHP files. Web server is configured to send the request to php.exe or some other system such as PHP-FPM, which processes the file and returns back to the web server to send it to the user. Processing of the file converts echo "<div>$variable</div>"; to clean HTML <div>I am awesome</div>. This processing system (php.exe or PHP-FPM) tag team with web server to serve to the browser what it can render.
Is it possible to cross-render languages?
Yes, you can in multiple ways. One of the common ways is to find the best processing system for the language of choice. For example, PHP can be processed with PHP-FPM running as a service. So, http://someurl.com/test/index.php could run through PHP-FPM. Python may use WSGI and you may choose gunicorn to process Python files. In that case, your webserver can be asked to send python-related directories/subdomains directly to gunicorn (essentially a proxy).
Reverse proxy
Let's say you have multiple sites with multiple language needs.
http://py.someurl.com serves Python/Django
http://someurl.com serves straight HTML
http://ph.someurl.com services PHP
http://js.someurl.com is powered by NodeJS
py.someurl.com could run on the server using gunicorn web server (or other wsgi-friendly servers) on port 8000. Node could be serving using Express web server on port 9000.
You could run NGINX server that serves straight HTML and also serves ph.someurl.com by sending requests to PHP-FPM service. It can also be configured to take all requests to js.someurl.com and hand it off to http://localhost:9000 where Node will service the request and send output back to NGINX and NGINX can send the request to the browser. Similarly, requests to py.someurl.com can be sent to localhost:8000 where gunicorn processes the request and sends the request back to NGINX, which forwards the request to the browser.
From a user's perspective, all they know is the NGINX server. All the other things in the background are known to NGINX. NGINX, in that case, serves as a web server and a proxy.
There are a lot of examples of implementing a TCP/IP-WS stack in all kinds of languages, also in PHP/CLI. But that is not what I'm looking for.
For http protocol there is Apache webserver software. It listens on default http port 80 for incoming requests. On shared hosting servers it can host an array of domain names and the incoming request url is mapped to the right served directory/file in the "hostAccountDir/domainName/docRoot/".
In this model each PHP script is a "specialized HTTP/application level" server; and does not need to invent/implement the TCP/IP-HTTP stack. Fortunately Apache does that for all PHP scripts.
Is there such a thing for Websockets, listening on port 9000(?), forking to the served directory/file... etc?
Apache powers more than 70% of websites today, but new alternatives are gaining market share. Apache is a reliable server, but it takes considerable memory to run. In some situations other web servers can perform better. The best-known alternative open source HTTP servers are lighttpd, nginx, and Cherokee.
PHP-FPM can listen on multiple sockets. It also listen on Unix sockets, or TCP sockets.
nginx is an HTTP server and mail proxy server. It has been running for more than two years on many heavily loaded Russian sites, and it has become more popular in the rest of the world, to the point where today it’s used by 6.5% of all websites.
For more details refer to the links below.
https://serversforhackers.com/video/php-fpm-configuration-the-listen-directive
https://linuxaria.com/article/apache-alternatives-for-serving-php
I was wondering if its possible create a website combined with NodeJs, Websocket and php in the same Apache server. Is there any documentation that can i read?
"In the same Apache server", No. node.js does not run in Apache. It runs by itself.
But, you can use multiple technologies on the same server. For starters, you could have two completely separate web servers running on separate ports, one that was Apache + PHP + webSocket and another that was node.js + webSocket.
But, node.js does not use Apache. Instead, node.js would typically be configured to be it's own web server all by itself. So, you don't typically run an Apache server and have some requests through it go to PHP and some go to node.js.
Using PHP and node.js together depends entirely upon what you're trying to do with them. You could have your web server as a node.js server and then have some requests that node.js receives actually execute some PHP and get the results from running a PHP script. And, you could do the reverse too with a PHP script fielding the request and then manually running a node.js script for some requests.
To answer any more fully, we need to know what you're really trying to do with PHP, node.js and webSockets.
FYI, you could set up an NGINX proxy on port 80 and configure it to direct some requests to your Apache/PHP server (running on a different port) and other requests to your node.js server (running on a different port). Incoming webSocket requests would then be directed to one of the two servers.
I've got Apache (running PHP and serving static content) and NodeJS (for websockets) running on the same server under the same domain (different ports). I'm not using nginx. I've already got the webclient communicating to both successfully, but now I want to close the communication loop and have Apache and NodeJS talk to each other.
It makes sense that they should be able to talk to each other, but I'm not entirely sure the best way to make it happen. What methods are there, and which way do you suggest?
If you are talking about the communication of the app running on apache and node app, yes it is possible. You just have to write the interfaces of your applications as services, then you can just use standard HTTP methods for communication.
I need to deploy a Django project on a shared server which I have no root access for, and no administration capabilities whatsoever.
Each user on the server has a dedicated directory from which Apache serves that users files (public URL would be /~username/).
Problem is, Apache on this server has no CGI capabilities, no mod_python, no mod_wsgi. I can work with PHP, however.
What hacks do I have to deploy a Django project on this server, maybe employing PHP somehow?
This is in no way a production scenario, and any hack you can think of which will work would be great. Ignore any performance or scalability factors - this is only a POC.
Without mod_python, mod_wsgi, or fastCGI, you won't be able to do it directly.
I'm thinking what you might have to do is run the django app as standalone, listening on another port, then basically use PHP to proxy requests to it.
So you do your
python manage.py runserver 9999
maybe starting it with a nohup instead to keep it running when you logout:
nohup python manage.py runserver 9999 &
Then, in ~username, you make a proxy.php script that takes any additional PATH_INFO and makes a request to localhost:9999, passing along HTTP headers, collects the response, and sends it back to the browser.
So, eg, the browser requests http://example.com/~username/proxy.php/some/path/ and the PHP script requests http://localhost:9999/some/path/ and sends along the results.
I'm not a PHP programmer so I can't exactly show you how to write that, but I'm sure someone out there must have implemented an HTTP proxy in PHP.
If you have .htaccess support in that directory and apache has mod_proxy_http enabled, you could just have apache directly proxy the request. The documentation is pretty easy to follow. But if they don't have CGI enabled, they probably don't have that set up either.
Of course, the easiest thing would be if you could just get away with django running and listening on a public facing port and access it directly. Ie,
python manage.py runserver example.com:9999
and access it directly as http://example.com:9999/