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

Eine Datei per HTTP-Response mit Dateinamens-Vorschlag FILE_NAME vom Server zum Client zu transferieren geht so:

Per Location Redirection

Location: URL
Content-Disposition: attachment; filename="FILE_NAME"

Per direkter Übertragung

Content-Type: TYPE/SUBTYPE
Content-Disposition: attachment; filename="FILE_NAME"

FILE_CONTENT

Die direkte Übertragung hat den Vorteil, dass die Datei nach dem Download serverseitig sofort gelöscht werden kann, falls sie nicht mehr gebraucht wird. Das ist bei einer Location Redirection nicht möglich, da der Client sie asynchron abruft.

Links

• Content-Disposition - RFC 2616 (June 1999)
• Content-Disposition - RFC 6266 (June 2011)

Der schon etwas in die Jahre gekommene, aber für Webanwendungen immer noch hervorragende persistente Perl-Interpreter speedy kompiliert unter neueren Perl-Versionen nicht mehr.

Der Versuch endet mit dem Fehler:

speedy_perl.c: In function ?find_scr?:
speedy_perl.c:258:24: error: expected expression before ?SpeedyScript?
  speedy_new(retval, 1, SpeedyScript);
                        ^
../src/speedy_backend_main.h:41:39: note: in definition of macro ?speedy_new?
 #define speedy_new(s,n,t) New(123,s,n,t)

Ursache ist, dass das C-Makro New() aus dem Perl-CORE (CORE/handy.h), nicht mehr existiert. Dies ist offenbar seit Perl 5.10 der Fall.

Die Lösung ist, anstelle des Makros New() das Makro Newx() zu benutzen. Hierzu muss in src/speedy_backend_main.h

#define speedy_new(s,n,t)       New(123,s,n,t)

durch

#define speedy_new(s,n,t)       Newx(s,n,t)

ersetzt werden.

Dann kompilieren die Quellen fehlerfrei. Getestet unter Perl 5.20.2.

Ein weiteres Problem tritt bei Perl 5.22.1 (mit gcc 5.3.1) auf:

In file included from ../src/speedy_inc.h:90:0,
                 from speedy.h:2,
                 from speedy_backend_main.c:24:
../src/speedy_file.h:54:19: warning: inline function
    ?speedy_file_set_state? declared but never defined
 SPEEDY_INLINE int speedy_file_set_state(int new_state);
                   ^

Dies lässt sich dadurch beheben, dass in src/speedy_inc.h die Macro-Definition SPEEDY_INLINE geändert wird zu

#ifdef __GNUC__
#define SPEEDY_INLINE /* __inline__ */
#else
#define SPEEDY_INLINE
#endif

Zum Testen (Perl 5.28.1) muss entgegen dem üblichen make test im Wurzelverzeichnis erst in das Unterverzeichnis speedy gewechselt werden:

$ cd speedy
$ make test

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

Per Default wird bei mod_perl derselbe Perl-Interpreter für alle Virtual Hosts genutzt. Das kann zu Problemen führen, wenn die Applikationen unterschiedliche Versionen derselben Module nutzen.

Dies kann bei mod_perl 2.0 mit der PerlOption +Clone ausgeschlossen werden:

<VirtualHost ...>
PerlOptions +Clone
</VirtualHost>

Die Option +Clone bewirkt, dass für den betreffenden Virtual Host ein eigener Interpreter-Pool genutzt wird. Dieser entsteht durch Klonen des Parent-Interpreters (welcher eventuell schon eine Startup-Initialisierung erfahren hat).

Ein Interpreter-Pool mit einem gänzlich neuen Parent-Interpreter wird bei Angabe von +Parent erzeugt:

<VirtualHost ...>
PerlOptions +Parent
</VirtualHost>

Um dem Interpreter einen (oder mehrere) eigene Suchpfade mitzugeben, kann die Perl Standard-Option -I verwendet werden:

PerlSwitches -I/var/www1/modules

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