nicht angemeldet
CGI-Script liefert SHTML-Seite zurück
Hallöchen zusammem,
wie überrede ich eigentlich den Apache, daß er die SSI-Befehle in der Ausgabe eines CGI-Scripts interpretiert? Da ja der Webserver die Endung .shtml erwartet, die Endung aber .cgi ist, ignoriert er die include-Statements. Ein Umbenennen der Scripts von *.cgi in *.shtml hat's leider auch nicht gebracht ("Method Not Allowed"). Irgendwie steh' ich grad' auf'm Schlauch...
Gruß,
Stefan
-
Hi,
wie überrede ich eigentlich den Apache, daß er die SSI-Befehle in der Ausgabe eines CGI-Scripts interpretiert? Da ja der Webserver die Endung .shtml erwartet, die Endung aber .cgi ist, ignoriert er die include-Statements. Ein Umbenennen der Scripts von *.cgi in *.shtml hat's leider auch nicht gebracht ("Method Not Allowed"). Irgendwie steh' ich grad' auf'm Schlauch...
wozu soll das gut sein ? Wenn du schon ein CGI Script hast, lass die Daten doch vom CGI Script ausgeben, warum willst du extra wieder einen Umweg über SSI und dann wieder zurück zum Server machen, wenn du doch schon am Server bist ?
-
Hallöchen zusammem,
wie überrede ich eigentlich den Apache, daß er die SSI-Befehle in der Ausgabe eines CGI-Scripts interpretiert? Da ja der Webserver die Endung .shtml erwartet, die Endung aber .cgi ist, ignoriert er die include-Statements. Ein Umbenennen der Scripts von *.cgi in *.shtml hat's leider auch nicht gebracht ("Method Not Allowed"). Irgendwie steh' ich grad' auf'm Schlauch...
Würde sagen, das geht nicht.
Du kannst nicht mit einem Application Server eine Seite ausgeben, die danach noch durch einen anderen gehen soll.
Analog: stell Dir vor, Du hättest eine PHP-Seite, die JSP-Code generiert, der dann noch ausgeführt werden soll... -
use Mosche;
wie überrede ich eigentlich den Apache, daß er die SSI-Befehle in der Ausgabe eines CGI-Scripts interpretiert?
Es gibt durchaus unterschiedliche Wege, das ganze zu erreichen.
1. Was ich sicher weiß:
Es gibt das Modul CGI::SSI (für Perl/CGI-Scripte), welches die Perl-Ausgaben auf STDOUT nach SSI Befehlen durchforstet und diese interpretiert. Ist aber noch relativ jung (0.53) und macht (bei mir) einige Probleme.2. Was ich gehört habe:
Wenn ich es richtig verstanden habe, kann der Apache 2 das, was du willst. Dort kann man die Ausgaben eines Handlers noch durch weitere Handler schicken. Vielleicht kann dir jemand anderes dazu noch genauere Informationen geben.use Tschoe qw(Matti);
-
use Mosche;
wie überrede ich eigentlich den Apache, daß er die SSI-Befehle in der Ausgabe eines CGI-Scripts interpretiert?
Wenn ich es richtig verstanden habe, kann der Apache 2 das, was du willst. Dort kann man die Ausgaben eines Handlers noch durch weitere Handler schicken. Vielleicht kann dir jemand anderes dazu noch genauere Informationen geben.
Ich habe jetzt noch mal genauer nachgeschaut, und habe auf http://httpd.apache.org/docs-2.0/new_features_2_0.html folgendes gefunden:
"Filterung
Apache-Module können jetzt als Filter entwickelt und zur Filterung des rein- und rausgehenden Datenstroms des Servers eingesetzt werden. Hierdurch kann beispielsweise die Ausgabe von CGI-Skripten durch den INCLUDES-Filter von mod_include bearbeitet werden und so Server-Side Include-Anweisungen ausgeführt werden."Das ist genau das, was du suchst und der Webserver ist auch die optimale Stelle, um dein Problem zu lösen - das ist also optimal.
use Tschoe qw(Matti);
-
-
Vielen Dank Euch allen,
warum ich das so machen will, ist eigentlich ganz einfach:
a) kurze Antwort: Um mir Arbeit zu sparen. :-)
b) längere Antwort: Weil ich in jede meiner Seiten immer 2 Standard-Include-Dateien einbinde, also:
<!--#include virtual="include1.txt" -->
Inhalt der Seite
<!--#include virtual="include2.txt" -->
Und genauso (einfach) möchte ich nun auch eine von Perl generierte Seite mit Suchergebnissen aufbereiten.
Am Webserver selbst kann ich nichts ändern, da mir der nicht gehört. Also wird mir wohl nur die Möglichkeit bleiben, die include-Anweisungen irgendwie in Perl "nachzubauen"...
Gruß,
Stefan-
Hi Stefan
b) längere Antwort: Weil ich in jede meiner Seiten immer 2 Standard-
Include-Dateien einbinde, also:
<!--#include virtual="include1.txt" -->
Inhalt der Seite
<!--#include virtual="include2.txt" -->Also wird mir wohl nur die Möglichkeit bleiben, die include-
Anweisungen irgendwie in Perl "nachzubauen"...das ist aber erstens sehr einfach (auch nur ca. 10 Zeilen) und zweitens
sogar performanter als das, was Du bisher tust.
Denn ein "include virtual" bewirkt einen zusätzlichen internen HTTP-
Zugriff innerhalb des Webservers! Dafür muß also ein Haufen Arbeit
erledigt werden.
Ein Dateizugriff, eine while (<HANDLE>)-Schleife zum Ausgeben der Zeilen
und das Schließen der Datei sind dagegen Kleinkram.
Und wenn Du das in vielen Skripten brauchst, dann mache ein eigenes
Modul daraus und binde das überall ein - dann hast Du insbesondere diese
Dateinamen nur an einer einzigen Stelle, was die Sache änderungs-
freundlich hält (viel änderungsfreundlicher als bisher, zudem ...).Viele Grüße
Michael-
Hi Michael,
Also wird mir wohl nur die Möglichkeit bleiben, die include-
Anweisungen irgendwie in Perl "nachzubauen"...das ist aber erstens sehr einfach (auch nur ca. 10 Zeilen) und zweitens
sogar performanter als das, was Du bisher tust.Naja, die reine include-Sache hatte ich in 4 Zeilen hinbekommen, mußte das Ganze allerdings noch ein wenig erweitern, da ich zuvor nicht bedacht hatte, daß ja das Script im cgi-Unterverzeichnis läuft und somit die relativen Links und die Grafikreferenzen in den inkludierten Dateien nicht mehr stimmen. Herausgekommen ist dann sowas, das ganz gut funktioniert:
sub IncludeFile
{
my $FileName = shift;
open(DATEI,"$FileName");
my @Zeilen = <DATEI>;
close(DATEI);
foreach $Zeile (@Zeilen)
{
$Zeile =~ s/background="([^:?]+?)"/background="/$1"/g;
$Zeile =~ s/img src="([^:?]+?)"/img src="/$1"/g;
$Zeile =~ s/a href="([^:?]+?)"/a href="/$1"/g;
print "$Zeile";
}
}Das könnte man eventuell noch optimieren (bin kein Perl-Experte), aber für meinen Zweck genügt es erst mal...
Viele Grüße,
Stefan-
Hi Stefan,
Naja, die reine include-Sache hatte ich in 4 Zeilen hinbekommen,
mußte das Ganze allerdings noch ein wenig erweitern, da ich zuvor
nicht bedacht hatte, daß ja das Script im cgi-Unterverzeichnis
läuft und somit die relativen Links und die Grafikreferenzen in
den inkludierten Dateien nicht mehr stimmen.
Herausgekommen ist dann sowas, das ganz gut funktioniert:Ich hätte innerhalb von $FileName absolute URLs auf die entsprechenden
Objekte verwendet. Reicht das nicht auch?Viele Grüße
Michael-
Hi Michael,
Ich hätte innerhalb von $FileName absolute URLs auf die entsprechenden
Objekte verwendet. Reicht das nicht auch?Mit open() eine URL öffnen? Wußte gar nicht, daß das geht...
Aber in $FileName steht schon ein absoluter Pfad wie z.B. /usr/home/xyz/www/include1.txt - wenn auch der als Variable übergeben wird.
Gruß,
Stefan-
Nochmal hi Michael,
ah jetzt ja... jetzt weiß ich, was Du damit meinst:
Ich hätte innerhalb von $FileName absolute URLs auf die entsprechenden
Objekte verwendet. Reicht das nicht auch?Hmm, stimmt eigentlich... auf die einfachsten Lösungen kommt man manchmal nicht. ;-)
Gruß,
Stefan
-
-
-
-
-