Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

As far as I understand, there are basically 3 options for doing server-side scripting these days:

  1. Using scripting languages that can be directly interpreted/executed by the web server (e.g., PHP and ASP), where the scripts are interpreted/executed on the fly (i.e., as HTTP requests come), the output is embed into HTML pages is then sent back to the client.

  2. Using any language (e.g., C, C++, PERL, Python) the operating system of the server is capable of executing (either using an interpreter or using the executable file already compiled) and then using CGI to communicate between the web server and the OS. Output of the scripts comes via CGI to the server in the form of complete HTML pages, and is then sent back to the client.

  3. Using Java on a server that can handle servlets/JSPs, which is pretty much the same idea as option 1 above, except using Java instead of PHP/ASP.

Questions:

  1. Is my understanding so far on track, or did I get something wrong?

  2. Are ASP and PHP the only languages that can be interpreted and executed directly by a web server?

  3. Where does Ruby fall in the classification above? Can it be interpreted/executed by servers like PHP? Or does it communicate via CGI?

  4. Is server-side scripting via CGI becoming obsolete or not at all?

share|improve this question
add comment

3 Answers

up vote 10 down vote accepted

Your understanding is correct, if you're from the past. You're pretty much describe as it looked like in 1990s.

Yes, many languages can be executed directly by a web server plugin. Right on for PHP, mod_php for Apache is still the most popular way to host it. However, high-traffic sites use more modern approach, using web server only as a proxy for FastCGI (in case of PHP it's PHP-FPM)

the output is embed into HTML pages is then sent back to the client.

I think you're referring to early 90's so called spaghetti code, however modern approach is to use one of many MVC frameworks. In case of PHP that would mean for example Zend Framework (there are numerous alternatives).

As for ASP, you're probably referring to so called "classic ASP", which is obsolete. Currently it's ASP.NET, which can use any of .NET languages (C# being the most popular), and of course the .NET framework.

C and C++ are not typically used for web application. If so, such services are implemented either as stand alone servers, as module for web server or as FastCGI.

Perl can be executed directly from web serve module using mod_perl. There is also PSGI, which is basically clone of Python's WSGI.

Python is very popular language for web apps. It can be directly executed from Apache web server via mod_python, however that is obsolete and not recommended. Currently the way to go with Python is either via WSGI server module. WSGI server implemented in Python (eg. CherryPy, WebPy) or using stand alone Python web stack (Tornado and Twisted's Web module are fine examples). And of course again, you'd most probably will be using WSGI compatible MVC framework, Django is the most popular one (again, multiple alternatives available).

Ruby, again very popular language for web apps. Best known for web framework Ruby on Rails, which again is MVC. You can execute Ruby directly from server module via mod_ruby or via FastCGI.

Servlets/JSP are executed in stand-alone J2EE application servers, such as JBoss or Tomcat. It's more commonly used to add web interface to business system rather than to create stand alone web apps.

Classical CGI (ie. spawning process on each request) has become obsolete many years ago. It has been replaced by FastCGI (where process is long-running, rather than spawned on each request), server modules, interfaces such as WSGI and clones and stand-alone solutions.

Also the paradigm of the request processing has evolved, with CGI it was process per request. Then was process pool (or thread pool), each process (thread) handling one request at a time. However now, most modern approach is for web servers and stand-alone frameworks to use event-driven programming.

share|improve this answer
    
I thought Django was mainly a CMS, for news sites etc. Can it be used to build regular websites, say like an eCommerce site? –  aml90 Feb 4 '12 at 18:08
1  
@amalantony django is a web framework. It is a set of guidelines and libraries that help you write software like a CMS. –  Burhan Khalid Feb 5 '12 at 4:18
1  
@amalantony: as burhan said, Django is web framework, not CMS at all. It can be used for building CMS, and there are multiple CMS packages build on top of it (djangopackages.com/grids/g/cms) just as well as eCommerce (djangopackages.com/grids/g/ecommerce) and about anything else you can think of. –  vartec Feb 5 '12 at 12:37
add comment

Let me preface this by saying this is extremely generic and simplified view of what happens.

Web server software (like Apache or IIS) does not interpret any code; it doesn't know how to. All it knows how to do is take a request, look it up in some location on the filesystem, and then send the item requested back to the browser. That's all it does - at a very simple level. This is why when you install Apache and add some php file to the DocumentRoot, you don't get the executed PHP result; just the file back.

The first step in getting the server to do something other than serve files is to add code that tells it to do something else when a specific file is requested; otherwise all it will do is try to serve the file according to its default mime type (which is usually text/plain). This is why when you have an incorrectly configured server, and you request index.php, you see the source code for the file instead of the intended result.

So to get a web server to "understand" PHP, you have to tell it what to do when a request for a file with the .php extension comes in. This is where mod_php comes in. This module offloads the request to a PHP interpreter (how it does that can be configured), which then reads the file, executes the code, compiles the results; and sends the results back to the server, which in turn delivers the results to the client. You then configure the webserver so that all files that have .php in the end should be handled by mod_php.

This basic workflow is applied with other languages as well; the only difference is what the server 'offloads' the request to.

The case for PHP is explained above, there is similarly mod_python, and fastcgi, wsgi and other established protocols on offloading requests that a web server is not designed to handle.

Most common implementations have a long running process that waits for a request on a specific port (or socket). The web server is then configured as a proxy, so that it passes any requests that match a specific pattern to this long-running process and then read the results back.

This is how ruby on rails (rack), python scripts (with wsgi) work.

This is also why simple proxy-like web servers like nginx are very popular. They only do the very basic tasks of a traditional web server - serve the "static" files, and are very good at offloading requests to other proxy servers to handle things like PHP, Python, ASP, et. al.

So in the end you have the web server - which takes care of the static files, anything that doesn't need processing.

You have another process, which knows how to deal with your code (for example, a process that runs the PHP interpreter, or a uWSGI server). This sits and waits for requests from the web server.

Finally, you have systems like upstart and supervisor that manage these processes for you.

Hope this clarifies the matter.

share|improve this answer
    
Helped a lot, thanks. A further question: how come PHP and ASP are the only languages that allow you to have scripts directly embed in pages (e.g., index.php)? –  daniels Feb 4 '12 at 16:57
    
@daniels they aren't - I know you can embed C# or VB.NET in ASP.NET pages - there are bound to be more... –  Murph Feb 4 '12 at 17:05
    
@daniels: It's not that others can't, it's that it has long been accepted that it is better to separate the markup from the logic. You can write plenty of Ruby into your ERB files, or C# into your aspx files, if you want, but why do that when you can keep it nicely segragated? –  pdr Feb 4 '12 at 21:04
    
@pdr, gotcha, thanks. –  daniels Feb 4 '12 at 22:28
add comment

There is a 4th option, that's used in the most 'serious;' web sites like banks or other financial services: the n-tier approach which is a little like CGI, except the CGI process runs on a different server, the webserver code is very thin (just enough to reformat data into html) and calls the 'cgi' services via network protocols such as RPC or SOAP.

Its still the same basic approach that uses a webserver as a gateway between the http request made by the client browser and a 'code engine' that hosts business logic. Note that in this case the webserver will pass the request to a scripting engine in one language (eg PHP or XSLT) that in turn calls another service that provides it with raw data, the web script is used solely to format that data into the html page that is delivered to the browser.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.