31.16.4.127 - - [15/Jul/2015:12:27:34 +0200] "GET /path/script.cgi?a=b HTTP/1.1" 302 583 "http://host.domain/page" "Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.1.0"

Der Aufbau der access.log-Datei, die ein Apache HTTP-Server per Default schreibt, ist in mehrfacher Hinsicht suboptimal:

• Information ist unpraktisch formatiert: Der Request-Zeitpunkt wird als [15/Jul/2015:12:27:34 +0200] (Formatelement %t) aufgezeichnet. Ein ISO-8601-ähnlicher Aufbau à la 2015-07-15 12:27:34 wäre besser lesbar und verarbeitbar. Zudem wird die Zeitzone im Normalfall nicht benötigt (da der Server ja nur in einer Zeitzone läuft, die bekannt sein sollte).

• Information ist zusammengesetzt, die besser getrennt sein sollte: Der Request wird als eine Zeichenkette "GET /path/script.cgi?a=b HTTP/1.1" (Formatelement %r) aufgezeichnet. Darin sind vier Teilinformationen enthalten:

  1. die Request-Methode (GET),

  2. der URL-Pfad (/path/script.cgi),

  3. der (optionale) Query-String (?a=b),

  4. das Request-Protokoll (HTTP/1.1).

  Eine Zerlegung ist nicht ganz einfach, da der Query-String optional ist. Besser wäre es, die Information in getrennten Feldern abzulegen (URL-Pfad und Query-String können zusammengelegt werden).

• Interessante Information fehlt: Z.B. fehlt die Ausführungsdauer des Requests, die insbesondere bei der Performance-Optimierung von dynmisch generierten Inhalten hilfreich ist, sowie Hostname und Port, an die der Request gegangen ist, was bei einem VirtualHost-Setup von Nutzen sein kann. Auch der Content-Type der Response kann interessant sein, um Logeinträge danach filtern zu können.

• Zeilen lassen sich schlecht in ihre Teilinformationen zerlegen: Eine einfache Trennung auf Whitespace geht nicht, da manche Felder Whitespace enthalten. Solche Felder sind in doppelte Anführungsstriche eingefasst. Aber nicht alle. Der Aufruf-Zeitpunkt ist in eckige Klammern eingefasst (s.o.). Fehlende Werte werden durch einen Bindstrich (-) dargestellt. Aber auch nicht immer. Für den Query-String (Formatelement %q) gilt dies nicht.

Aufgrund dieser Ungereimtheiten definiert man sich am besten ein eigenes Logfile-Format. Zum Glück ist dies mit der Apache-Direktive LogFormat leicht möglich. Ich verwende folgende Definition, mit einem senkrechten Strich als eindeutigem Feldtrenner:

LogFormat "%{%Y-%m-%d %H:%M:%S}t|%h|%>s|%L|%D|%I|%O|%{Content-Type}o|
    %m|%v|%p|%U%q|%H|%{Referer}i|%{User-Agent}i" NAME

Verwendete Formatelemente (die mit + gekennzeichneten Informationen kommen im ursprünglichen Format nicht vor):

%{%Y-%m-%d %H:%M:%S}t Request-Zeitpunkt
%h .................. Client-IP oder -Name
%>s ................. finaler HTTP Status (200, ...)
%L .................. + error.log wurde geschrieben
%D .................. + Ausführungsdauer in Mikrosekunden
%I .................. + Bytes empfangen
%O .................. Bytes gesendet
%{Content-Type}o .... + Content-Type Header der Response
%m .................. Request-Methode (GET, POST, ...)
%v .................. + Hostname
%p .................. + Port
%U .................. URL-Pfad
%q .................. Query-String
%H .................. Request-Protokoll (HTTP/1.0, ...)
%{Referer}i ......... Referer Header des Requests
%{User-Agent}i ...... User-Agent Header des Requests
NAME ................ Name es Log-Formats

Ein weiteres interessantes Formatelement ist

%{COOKIE}C .......... + Wert des Cookie COOKIE

das in Anwendungen, die Cookies nutzen, nützlich sein kann. Ich füge es bei Bedarf am Ende hinzu.

Links:

• LogFormat-Direktive

• Liste aller Format-Elemente

2015-07-15 12:27:34|31.16.4.127|302|-|7273|400|583|text/html|GET|myhost.mydomain|80|/path/script.cgi?a=b|HTTP/1.1|http://host.domain/page|Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.1.0

Das Aufsetzen einer CGI-Applikation ist kein Zauberwerk. Es führen allerdings viele Wege nach Rom und es kann leicht passieren, dass ein "from scratch" erstelltes Setup überkomplex und krautig wird. Es folgt - in vier Schritten - das Setup, mit dem ich beim Erstellen von CGI-Applikationen starte. Es ist aufgeräumt und beruht auf technisch sauberen Konzepten. Von diesem Ausgangspunkt aus lässt sich eine beliebig umfangreiche Applikation aufbauen, ohne später den am Anfang gesteckten Rahmen verlassen zu müssen.

1. Applikationsstruktur im Dateisystem

Jede nicht-triviale Applikation sollte sich im Dateisystem auf drei Bereiche verteilen. Wir wählen nach moderner Unix-Konvention hierfür eine /opt-Struktur:

• /opt/<application> (Programmcode und statische Daten)
• /etc/opt/<application> (Konfiguration)
• /var/opt/<application> (Bewegungsdaten)

<application> ist der Name der Applikation.

/opt/<application>/
  +-- ...
  +-- www/
  +-- bin/index.cgi

/etc/opt/<application>/
  +-- ...
  +-- apache.conf

/var/opt/<application>/
  +-- ...
  +-- access.log
  +-- error.log

Erläuterung:

• Das Subverzeichnis www/ ist das DocumentRoot-Verzeichnis der Applikation. Hier werden statische Inhalte abgelegt, die vom HTTP-Server direkt ausgeliefert werden. Es ist das einzige Verzeichnis, dessen Inhalt von außen zugegriffen werden kann.

• Die Datei bin/index.cgi ist das CGI-Programm, das alle dynamischen Inhalte generiert. Es ist außerhalb von DocumentRoot installiert, damit der Programmcode - auch im Falle einer Fehlkonfiguration - nicht von außen eingesehen werden kann.

• Die Datei apache.conf enthält die Apache-Konfiguration der Applikation (s.u. "Apache-Konfiguration"). Die Datei wird in das Konfigurationsverzeichnis des Apache-Servers gelinkt (s.u. "Kommandos"), da sie dort gebraucht wird.

• Die applikationsspezifischen Logdateien access.log und error.log, die der HTTP-Server schreibt, liegen im Bereich der Bewegungsdaten.

2. CGI-Programm (index.cgi)

Hier ein minimales CGI-Programm. Es gibt die IP-Adresse des Client aus.

#!/usr/bin/perl -T

use strict;
use warnings;

print <<"__HTTP__";
Content-Type: text/plain

$ENV{'REMOTE_ADDR'}
__HTTP__

# eof

3. Apache-Konfiguration (apache.conf)

Die Apache-Konfigurationsdatei vereinbart einen VirtualHost und zwei Verzeichnisse:

# Apache Config for <application>

<VirtualHost *:80>
  ServerName [host].[domain]
  DocumentRoot /opt/[application]/www
  ScriptAlias /index.cgi /opt/[application]/bin/index.cgi
  RedirectMatch ^/$ /index.cgi
  ErrorLog /var/opt/[application]/error.log
  CustomLog /var/opt/[application]/access.log combined
</VirtualHost>

<Directory /opt/[application]/bin>
  Options ExecCGI
  Require all granted
</Directory>

<Directory /opt/[application]/www>
  Require all granted
</Directory>

# eof

Erläuterung:

• Die Angaben [host], [domain] und [application] sind Platzhalter, die passend zur jeweiligen Applikation gesetzt werden müssen.

• ServerName definiert die Domain, unter der die Applikation im Netz erreicht wird.

• DokumentRoot definiert das Verzeichnis für statische Inhalte (HTML-, CSS-, JavaScript-, Bilddateien usw.)

• SkriptAlias definiert das CGI-Programm für dynamische Inhalte. Als Name wird hier index.cgi vereinbart. Es kann auch anders heißen. Es wird aus dem bin-Verzeichnis heraus aufgerufen, das aus Sicherheitsgründen nicht unterhalb von DocumentRoot liegt.

• RedirectMatch definiert die Umschreibungsregel, mit der der Client auf das CGI-Programm gelenkt wird, wenn kein Pfad angegeben ist. Die Regel lenkt also auf den Start-URL der Applikation.

• ErrorLog und CustomLog definieren den Ort, an den die Server-Logdateien geschrieben werden, und - im Falle von CustomLog - zusätzlich das Format der Datei (combined).

• Mit der Option ExecCGI wird dem Webserver gestattet, im Verzeichnis /opt/[application]/bin das CGI-Programm index.cgi auszuführen.

• Mit Require all granted wird der Außenwelt bedingungsloser Zugriff auf die beiden Verzeichnisse /opt/[application]/bin und /opt/[application]/www eingeräumt.

4. Kommandos (für Apache 2.0 und höher)

Mit folgenden Kommandos wird das oben beschriebene Apache-Setup im Webserver aktiviert. Hierfür sind root-Rechte erforderlich.

1 - Apache-Konfiguration der Applikation verlinken (Debian):

# ln -s /etc/<application>/apache.conf /etc/apache2/sites-available/<application>.conf

2 - Apache-Konfiguration der Applikation aktivieren:

# a2ensite <application>

3 - Apache-Modul für CGI-Ausführung aktivieren:

# a2enmod cgid

4 - Apache-Setup in den laufenden Server übernehmen (Debian):

# service apache2 reload

Variante: Verdecktes CGI-Programm

Wird in die VirtualHost-Definition anstelle von

ScriptAlias /index.cgi /opt/<application>/bin/index.cgi
RedirectMatch ^/$ /index.cgi

die Definition

RewriteEngine on
RewriteRule ^/([A-Z0-9a-z/]+)$ /opt/<application>/bin/index.cgi/$1 [H=cgi-script]
RedirectMatch ^/$ /<start>

eingesetzt, tritt das CGI-Programm im URL nicht mehr in Erscheinung. Zusätzlich werden alle Pfade, die ausschließlich aus den Zeichen A-Z0-9a-z/ bestehen, via $PATH_INFO an das CGI-Programm übergeben.

Die RewriteEngine muss zuvor verfügbar gemacht werden mit:

# a2enmod rewrite

Mit der Direktive Redirect kann ein Seitenzugriff auf eine andere Seite umgeleitet werden. Die Umleitung schließt alle Subpfade ein, also Seiten mit gleichem Pfadanfang.

Möchte man ein Directory auf ein Subdirectory umleiten, klappt es mit Redirect nicht, da dies zu einer Endlos-Rekursion führt. Die Redirect-Regel

Redirect /a /a/b

führt bei Aufruf von /a zu der endlosen Kette von HTTP-Aufrufen

/a
/a/b
/a/b/b
/a/b/b/b
...

bis der Browser dies erkennt und mit einer Meldung wie

Redirect Loop: Redirection limit for this URL exceeded.

abbricht.

Die Lösung liefert die (leistungsfähigere) Direktive RedirectMatch. Mit dieser lässt sich der umzulenkende Pfad per Regex präzise eingrenzen:

RedirectMatch /a$ /a/b

Das Dollarzeichen verankert den Pfad /a am Ende des URL, so dass Subpfade nicht mehr matchen und die Rekursion unterbleibt.

Da durch die Regel keine Subpfade weitergeleitet werden, müssen die Zugriffe innerhalb von /a/b relativ sein.

Ist das Ausgangsdirectory das Root-Directory, muss auch der Anfang verankert werden, da jedes Verzeichnis auf / endet:

RedirectMatch ^/$ /a

Apache2::Reload ist ein Perl-Modul, das Module einer mod_perl-Applikation automatisch neu lädt, wenn diese geändert wurden. Andernfalls müsste der HTTP-Server neu gestartet werden um die Änderungen sichtbar zu machen, was während der Entwicklung umständlich ist und Zeit kostet.

1. Apache2::Reload von CPAN herunterladen

2. Apache Libs und Headerfiles installieren (Redhat-System)

   yum install httpd-devel.x86_64

3. Modul installieren

   perl Makefile.PL
   make
   make install

   (make test geht nicht ohne Apache Testumgebung)

4. HTTP-Config ergänzen:

   PerlModule Apache2::Reload
   PerlInitHandler Apache2::Reload

5. Apache neu starten

   apachectl restart