![]() |
Serverkonfiguration:
|
|
| |
| E-Mail: | |
|---|---|
| Homepage-URL: |
Bei Fragen zu diesem Beitrag bitte den Autor des Beitrags kontaktieren!
Wer nicht direkt von der "Programmierer-Ecke" kommt, wer also keinerlei Erfahrungen mit Programmiersprachen hat, hat bestimmt einen ähnlichen Weg "durchlaufen": Erst wird dank SELFHTML HTML gelernt, später etwas JavaScript dazu, dann werden die ersten Ergebnisse online gestellt, die Präsenz wächst, bald müssen serverseitige Lösungen her, also werden auch Perl oder PHP "studiert". Da das ständige Hochladen zum Testen der Perl-Skripte schnell mühsam wird, muss bald ein lokaler Webserver her, der auf dem eigenen Windows-PC installiert und konfiguriert werden kann.
Eigentlich gibt es nur einen Webserver, der den Namen verdient, und das ist der Apache. Da aber bei diesem Webserver und seiner Vielzahl an Konfigurationsmöglichkeiten der "Einstieg" für absolute Beginner sich als schwierig erweist, gibt es zum Anfängerglück noch den von vielen so genannten "kleinen" Webserver
Xitami. Installation und Konfiguration sind relativ einfach, der Webserver ist innerhalb weniger Augenblicke einsatzbereit. Schnell den Browser aufgerufen, http://localhost/ in die Adresszeile eingegeben, und schon ist die eigene Homepage in einer HTTP-Umgebung zu betrachten, genauso wie vom "außenstehenden" Server aufs Silbertablett, pardon, auf den Monitor geliefert! Somit lassen sich eigene Skripte solange testen, bis sie fehlerfrei und "reif" für einen Einsatz online sind!
Wer allerdings auf Server Side Includes (SSI) setzt, stößt schnell an die Grenzen des "kleinen" Webservers, wie die relativ häufig anzutreffende Frage im
SELFHTML-Forumsarchiv beweist. Der Xitami-Webserver kann nämlich gar keine Server Side Includes darstellen! Wird die mitgelieferte Dokumentation/FAQ zu Rate gezogen, ist dort folgendes zu lesen:
Xitami provides a standard SSI filter (PerlSSI) which requires a Perl interpreter. This is not meant for heavy-duty work, but is a good example of a filter. (We intend to develop a fast SSI module that will be embedded into the server directly.)
Und weiter:
SSI (server-side includes) is a fairly standard syntax which you can read about on the NCSA site. We implemented all the common SSI tags in the PerlSSI filter. To use this, you need Perl on your system (it should be on the PATH). The PerlSSI filter is slow, and meant as a work-around until we implement SSI the correct way, in the server itself. The PerlSSI filter is located in the Xitami directory itself. To run it, you must have Perl installed. The requirements for this filter are the same as for a Perl CGI program.
Im (deutschsprachigen) Klartext bedeutet dies: SSI sind im Xitami-Webserver noch nicht implementiert, statt dessen werden sie dank eines Filters namens PerlSSI eingebunden. Die Datei perlssi ist Bestandteil des Xitami-Pakets und befindet sich nach der Installation direkt im Xitami-Verzeichnis (C:\Xitami). Diese Datei ist jedoch so allgemein geschrieben, dass es aufgrund der individuellen Organisation auf dem eigenen PC ohne Anpassung des Dateicodes selten auf Anhieb möglich ist, SSI auf seinem lokalen Webserver darzustellen.
In den folgenden Abschnitten lernen Sie, wie Sie mit wenigen Änderungen im Perl-Code der Datei perlssi Ihren Xitami-Webserver dazu bringen, SSI in Ihren Webseiten korrekt anzeigen zu lassen. Anschließend wird Ihnen eine Datei mit einigen SSI-Anweisungen zum erfolgreichen Testen präsentiert.
perlssiDamit Sie sich in der Datei besser zurecht finden, wurde jede Zeile mit einer Nummer versehen. Sie können also, nachdem Sie zuvor Ihre Original-perlssi in ein anderes Verzeichnis gesichert haben, Ihre zu ändernde Kopie mit einem Texteditor öffnen und bearbeiten. Dabei sollten Sie einen Editor verwenden, bei welchem Sie den Zeilenumbruch ausschalten können (so dass die Reihenfolge der Code-Zeilen respektiert und diese nicht umgebrochen werden). Unter
weiterführende Links finden Sie die Adresse von EditPad Lite: Dieser Editor bietet diese Möglichkeit und es ist auch möglich, Zeilen direkt nach der Zeilennummer zu suchen. Es gibt aber auch andere Editoren, die beide Möglichkeiten bieten!
Dieser Artikel richtet sich in erster Linie an Anfänger und es war daher nicht vorrangiges Ziel, den gesamten Code der Datei perlssi zu erläutern. Vielmehr soll dieser Artikel auf die Stellen im Code aufmerksam machen, welche für eine einwandfreie Einbindung von SSI mit dem Xitami-Webserver geändert werden müssen. Ein Minimum an Kenntnisse in Perl sollten Sie daher schon mitbringen, zum Beispiel sollten Ihnen Begriffe wie
Shebang-Zeile,
Subroutinen und deren Aufruf nicht fremd sein... Ferner sollten Sie den SELFHTML-Kapitel über
Server Side Includes gelesen und verinnerlicht haben.
perlssiVergewissern Sie sich zu Beginn darüber, dass in der Datei defaults.cfg im Xitami-Verzeichnis folgender Eintrag vorhanden ist:
[Filter]
Shtml=perlssi
Der Eintrag sollte normalerweise bereits vorhanden sein und bewirkt, dass bei HTML-Dateien mit der Endung .shtml auf den PerlSSI-Filter zurückgegriffen wird.
Bei den nachfolgenden Änderungen in der Datei perlssi wird von folgender Konfiguration ausgegangen:
C:\ installiert (C:\Perl und C:\Xitami)www, Root-Verzeichnis) mit Ihren Webdateien befindet sich auf einer Festplattenpartition D:\, das Verzeichnis cgi-bin ist ein direkter Unterverzeichnis davon (Pfade: D:\www und D:\www\cgi-bin)Bei einer anderen persönlichen Konfiguration sollten Sie die beschriebenen Änderungen entsprechend anpassen. Es ist allerdings allgemein vom Vorteil, in seinem lokalen Webordner haargenau die gleiche Struktur nachzubilden, wie sie auf dem Server Ihres Providers zu finden ist. Nur so läßt sich mit dem lokalen Webserver zum Beispiel mit absoluten Pfaden arbeiten, die Anpassungen beim Testen von Perl-Skripten beschränken sich nur noch auf die lokal anders aussehenden Pfade (zum Beispiel müsste einer Variable $Verzeichnis den Wert "D:\\www\\verzeichnis" für das lokal getestete Perl-Skript zugewiesen werden, während das Online-Skript die Anweisung $Verzeichnis = "/public_html/verzeichnis"; o.ä. enthalten müsste.
Zuerst werden die zu Beginn des Skripts (Zeilen 32 bis 36) deklarierten Variablen überprüft:
$BINDIR = $ENV {CGI_ROOT}; # Location of CGI programs
$BINURL = $ENV {CGI_URL}; # CGI URL prefix
$DOCROOT = $ENV {DOCUMENT_ROOT}; # Location of web pages
$DOCPATH = $ENV {PATH_TRANSLATED}; # Document root, cut before '/'
$DOCPATH = $1 if $DOCPATH =~ /(.*)\//;
Kommentieren Sie die Zeile 33 aus, in dem Sie zu Beginn der Zeile ein zur besseren Übersicht von einem Leerzeichen gefolgtes Rautezeichen # eingeben:
$BINDIR = $ENV {CGI_ROOT}; # Location of CGI programs
# $BINURL = $ENV {CGI_URL}; # CGI URL prefix
$DOCROOT = $ENV {DOCUMENT_ROOT}; # Location of web pages
$DOCPATH = $ENV {PATH_TRANSLATED}; # Document root, cut before '/'
$DOCPATH = $1 if $DOCPATH =~ /(.*)\//;
Die hier als Wertzuweisungen notierten
Umgebungsvariablen $ENV {...} hängen von der Konfiguration des Xitami-Webservers ab. So ist $ENV {CGI_ROOT} der Pfad zu Ihrem cgi-bin-Verzeichnis (D:\www\cgi-bin) und $ENV {DOCUMENT_ROOT} der Pfad zu Ihrem Webordner www (D:\www). Die Umgebungsvariable $ENV {CGI_URL} ist leer, wenn Sie bei der Konfiguration Ihres Xitami-Webservers das entsprechende Feld CGI URLs start with: leergelassen haben (siehe unten stehendes Bild: Sollten Sie vorher hier etwas notiert haben, so löschen Sie den Eintrag jetzt). Aus diesem Grund wird die Variable $BINURL nicht benötigt und die Zeile 33 deswegen auskommentiert.

Konfigurationsseite des Xitami-Webservers - das Feld CGI URLs start with: bleibt leer.
Als nächstes wird die Zeile 69 auskommentiert. Es hat sich herausgestellt, dass der Aufruf der Subroutine MakePathname an dieser Stelle überflüssig ist, da der "relevante" Aufruf dieser Subroutine an anderer Stelle erfolgt (Zeile 147):
$infile = $sent; # &MakePathname; $target = $outfile;
Der nächste Schritt befaßt sich mit der eben genannten Subroutine MakePathname, welche in den Zeilen 244-266 definiert wird:
sub MakePathname {
$errno = 1;
$info = $infile;
if ($info =~ /^$BINURL\//) {
@split1 = split (/$BINURL\//, $info);
$info = join ('/', $BINDIR, $split1 [1]);
}
else {
$info = $DOCROOT.$info;
}
$outfile = $info;
if (!-e $outfile) {
print "<P>File not found: $outfile";
&GiveErrMsg;
}
else {
$errno = 0;
}
}
Sie erinnern sich? Unser erster Schritt war, die Zeile 33 ($BINURL = $ENV {CGI_URL};) auszukommentieren. Die Variable $BINURL existiert also nicht mehr. Aus diesem Grund sind die Anweisungen der Zeilen 247 bis 249 wirkungslos. Ersetzen Sie diese drei Zeilen durch die drei folgenden:
if ($info =~ /^\/cgi-bin/) {
$info =~ s/\/cgi-bin//g;
$info = $BINDIR.$info;
Hier wird in der if-Anweisung geprüft, ob die Variable $info mit der Zeichenkette /cgi-bin beginnt. Ist dies der Fall, wird diese Zeichenkette gelöscht (durch nichts ersetzt): $info =~ s/\/cgi-bin//g;. Anschließend wird der Variable $info einen neuen Wert zugewiesen, der sich aus dem Wert von $BINDIR und dem bisherigen Wert von $info (eben befreit von der Zeichenkette /cgi-bin) durch Zeichenkettenverknüpfung (engl.: concatenation) zusammensetzt. An dieser Stelle, wenn Sie beispielsweise mittels SSI die Ausgabe eines Skripts namens script.pl anzeigen lassen, hat die Variable $info den Wert D:\www\cgi-bin plus /script.pl = D:\www\cgi-bin/script.pl. Weiter unten wird dieser Wert der Variable $outfile zugewiesen: $outfile = $info; (Zeile 254). Wie der Mischmasch von Slashes und Backslashes wieder gerade gebogen wird, lesen Sie in den nächsten Erläuterungen. Hier die geänderte Subroutine MakePathname komplett:
sub MakePathname {
$errno = 1;
$info = $infile;
if ($info =~ /^\/cgi-bin/) {
$info =~ s/\/cgi-bin//g;
$info = $BINDIR.$info;
}
else {
$info = $DOCROOT.$info;
}
$outfile = $info;
if (!-e $outfile) {
print "<P>File not found: $outfile";
&GiveErrMsg;
}
else {
$errno = 0;
}
}
Nun befassen wir uns mit der wichtigsten Subroutine - sozusagen der Kernroutine - des Skripts perlssi: HandleSSI. Diese beginnt in Zeile 98, endet in Zeile 242 und ist in sechs Unterabschnitten unterteilt. Die Unterabschnitte sind if- bzw. elsif-Verzweigungen und stehen je für eine SSI-Anweisung. So behandelt der erste Unterabschnitt ab Zeile 99 die SSI-Anweisung #config: if ($ssi =~ /^config/i). Ab Zeile 117 wird in einem elsif-Zweig die SSI-Anweisung #echo behandelt, ab Zeile 143 die für ausführbare Dateien oder Programme/Skripte zuständige SSI-Anweisung #exec, ab Zeile 200 die SSI-Anweisung #include. Ab Zeile 212 wird die SSI-Anweisung zum Anzeigen des Datums der letzten Änderung einer Datei #flastmod und zuletzt wird ab Zeile 222 die SSI-Anweisung #fsize zum Anzeigen einer Dateigröße behandelt.
Die als nächste vorzunehmende Änderung betrifft einzig und allein die Behandlung der #exec-Anweisung, so dass wir unser Augenmerk auf die Zeilen 143 bis 199 lenken. Da lediglich eine einzige Änderung bzw. Ergänzung notwendig ist, beschränken wir uns im nachfolgenden Kasten auf das Anzeigen der Zeilen 143 bis 168:
elsif ($ssi =~ /^exec/i) {
if ($ssi =~ /cgi="([^"?]+)(\??([^"]*))"/i) {
$infile = $1;
$args = $3;
&MakePathname;
$var = $outfile;
if ($errno == 0) {
# We can now execute the CGI script in $var
$ENV {"QUERY_STRING"} = $3;
# First, handle MS-DOS systems
if (defined ($ENV {"COMSPEC"})) {
$var =~ s/\//\\/g;
# Try normal executable programs first
if ($var =~ /\.exe$|\.com$|\.bat$/i) {
$_ = `$var $args`;
}
else {
# Check file header to see if it's a script
# We're looking for '#! xxxx' or '/*! xxxx'
open (FOO, $var);
$_ = <FOO>;
chop;
close (FOO);
if (/^\#\!\s*(.+)|^\/\*\!\s*([^*]+)\*\//) {
Im elsif-Zweig wird zuerst geprüft, ob es sich hier um eine #exec-Anweisung handelt: elsif ($ssi =~ /^exec/i). Die Variable $ssi wird weiter oben im perlssi-Code deklariert (Zeile 81) und deren Wert entspricht der jeweiligen SSI-Anweisung ohne das einführende Rautezeichen. Wurde also in der .shtml-Datei die Anweisung: <!--#exec cgi="/cgi-bin/script.pl"--> notiert, hat die Variable $ssi den Wert exec cgi="/cgi-bin/script.pl".
Im darunterfolgenden if-Zweig (Zeile 144) wird mit Hilfe eines
regulären Ausdrucks der absolute Pfad des mit #exec einzubindenden Skripts extrahiert, bei unserem Beispiel also: /cgi-bin/script.pl. Dieser Wert wird in Zeile 145 der Variable $infile zugewiesen. Anschließend (Zeile 147) erfolgt der Aufruf der weiter oben erläuterten Subroutine MakePathname, in welcher die Variable $outfile einen Wert bekommt, der dem kompletten Pfad des zu behandelden Skripts entpricht. Allerdings enthält dieser Pfad, wie oben gesehen, sowohl Slashes als auch Backslashes.
Dem wird in Zeile 155 Rechnung getragen. Nachdem der Wert von $outfile in Zeile 148 einer weiteren Variable $var übergeben wurde ($var = $outfile;), werden hier alle in der Zeichenkette eventuell vorkommenden Slashes durch Backslashes ersetzt: $var =~ s/\//\\/g;. Danach ist der Pfad unseres Beispiels wieder korrekt: D:\www\cgi-bin\script.pl
Die angekündigte Ergänzung in diesem Skript-Abschnitt dient lediglich dazu, Ihnen viel Arbeit beim Testen von Skripten, die Sie mit der SSI-Anweisung #exec cgi einbinden, zu ersparen. Ohne die folgende Zeile müssten Sie für Ihre lokalen Tests die Shebang-Zeile (die allererste Zeile eines Perl-Skripts) wie folgt notieren: #!c:/Perl/bin/Perl.exe. Vor dem Hochladen auf dem Server Ihres Providers müssten Sie diese dann in #!/usr/bin/perl ändern, da Ihnen ansonsten einen "500-Fehler" (Internal Server Error) sicher wäre!
Notieren Sie also in Zeile 167, die ja schön leer ist, folgende Anweisung:
$_ =~ s/^\#\!\/usr\/bin\/perl/\#\!c\:\/Perl\/bin\/perl\.exe/g;
Nun übernimmt perlssi diese Arbeit für Sie! Obige Anweisung bewirkt nämlich, dass im Skript, das in Zeile 163 (open (FOO, $var);) zum Lesen geöffnet und dessen Inhalt im
vordefinierten Skalar $_ zeilenweise gespeichert wird, nach der Zeichenkette #!/usr/bin/perl gesucht und diese durch #!c:/Perl/bin/Perl.exe ersetzt wird. Sie brauchen also beim Testen nicht mehr auf die Shebang-Zeile zu achten!
Somit wären alle Änderungen und Ergänzungen in der Datei perlssi vorgenommen worden! Let's test it now!
Sie können jetzt auch die englischsprachigen Fehlermeldungen, welche ausgegeben werden, wenn zum Beispiel eine Variable nicht erkannt, eine Datei nicht gefunden wird o.ä., durch deutsche Texte ersetzen. Nachfolgend zwei Beispiele, wie Sie sie in Zeile 139 (print "<P>Unrecognised #echo variable: $var";) und in Zeile 172 (print "<P>Cannot execute $var";) finden:
print "<p>Unbekannte #echo-Variable: $var";
.
.
.
print "<p>Kann $var nicht ausführen!";
Hier finden Sie den kompletten, modifizierten Code der Datei perlssi ohne Zeilennummern (direkt zum Kopieren, Einfügen und Abspeichern):
modifizierte Datei perlssi
Die vorliegende Testdatei ssi_test.shtml besteht aus sechs Abschnitten. In jedem Abschnitt wird je eine andere SSI-Anweisung erläutert. Sie benötigen jedoch noch vier weiteren Dateien: zwei Textdateien für die SSI-Anweisungen #fsize, #flastmod und #include und zwei Perl-Skripte für die #exec-Anweisung. Sie können sich gerne an die nachfolgende Beispiele orientieren oder diese übernehmen. Die Datei ssi_test.shtml selbst können Sie direkt in Ihren Webordner kopieren: D:\www\ssi_test.shtml.
Erstellen Sie zwei Textdateien mit knappem Inhalt, zum Beispiel Hier kommen die ersten Neuigkeiten! und Und hier kommen die zweiten Neuigkeiten!, und speichern Sie diese in einem eventuell zu erstellenden Verzeichnis D:\www\news. Geben Sie den Dateien die Namen news1.txt und news2.txt.
Schreiben Sie zwei Perl-Skripte für eine einfache Ausgabe, zum Beispiel ein Skript namens script1.pl (Hallo Welt!) und ein zweites Skript script2.pl (Aber auch hallo, Welt!), die Sie in Ihr cgi-bin-Verzeichnis abspeichern (D:\www\cgi-bin). Beispiel script1.pl:
#!/usr/bin/perl print "Hallo Welt\n";
Weitere Erläuterungen darüber, was Sie sehen sollen oder nicht, entnehmen Sie direkt der Datei
Datei ssi_test.shtml.
Die folgenden Stellen werden empfohlen, um das obige Beispiel besser zu verstehen, oder um weitere Möglichkeiten und Details zu erfahren.
SELFHTML: Server Side Includes
SELFHTML: CGI/Perl
NCSA: Server Side Includes
W3C: Server Side Includes commands
Xitami-Webserver
ServerWatch: Going Lean and Mean With Xitami
EditPad Lite
© 2007
Impressum, für diese Seite:
patricka@selfhtml.org