Apache Basics and simple CGI scripts

Motivation

The web is ubiquitous today. Everything comes with built-in web servers and there are many free/open source web-servers available. For a long time Apache was the most used web server and it is still rather prominent today. It has recently been surpassed by nginx (pronounced: engine-x). Still the versatility of Apache and the time-tested security makes it a good choice for many applications.

Here you will learn the basics to get you started with running an apache web server, yet many of the concepts will apply to any web server.

Appache Configuration

Global Configuration

Apache has one main configuration file. This is depends on how apache was started and the default is dependent on your Linux distribution. E.g. in debian it is /etc/apache2/apache2.conf and in redhat it is: /etc/httpd/conf/httpd.conf

Within the main configuration there are usually Include statements that include other files. E.g.

IncludeOptional sites-enabled/*.conf

Which would include any .conf file from the sub-directory sites-enabled. Usually the configuration is split up into many files. E.g. one for each module that is included and one for each virtual web server that is hosted.

Independent whether this is in the main config file or in included files. Some directives are global: They change parameters of the server itself. E.g.

Listen 80
Listen 443
Listen 127.0.0.1:9980

The above would tell apache to create listen sockets of 443 and 80 on all ports and one additional port 9980 that is only available on the localhost.

Virtual Web Servers

A web server without encryption answers on port 80. If you have https encryption then it answers on port 443. If you have more then one IP you can choose which IP address the socket binds to.

When a web client connect they will ask for the URI part (the part behind the host name) but after the request the host name that should be sent is also transmitted (in http/1.1 requests). Thus the server can present different web pages depending on the host name.

So the server can discern what the client wants, either be the IP address and/or by the host name that the client requested. So we speak of IP-based and name-based virtual hosts.

With https protected services there is a little chicken-and-egg type problem: When the SSL connection is established the server needs to present the certificate for that server. If it has more virtual servers it does not know which, since the host name is only sent within the established session. To avoid this and to allow more then one virtual server with https protection on the same IP address the SNI was invented. SNI (server name indication) is supported by all modern browsers. With SNI the server name is already sent within the SSL handshake.

<VirtualHost 10.11.12.13:80>

ServerName www.test.example.org
ServerAlias test.example.org


ServerAdmin admin@example.org
DocumentRoot /var/www/testsever/


ErrorLog /var/log/apache/test.error_log
TransferLog /var/log/apache/test.access_log

RedirectPermanent /wuwien http://www.wu.ac.at

Alias /projectdata/ /home/anna/projectx/data/

</VirtualHost>

The above example defines a virtual host (you might want to place that in its own config file - but it works in the main file as well). The virtual host is on that private IP 10.11.12.13 and accepts requests on port 80. This configuration will only be used if the hostname that is sent matches the name in ServerName or ServerAlias. Documents will be served from the DocumentRoot and the config specifies the location of the log files.

You could specify many other directives within that block. One exmaple here is the RedirectPermanent. If a uses goes to http://www.test.exmaple.org/wuwien they will be redirected to another server.