<!--#exec funktioniert nicht

[alex]

Hi

Ich will einfach mittels ssi ein perl skript starten:
<!--#exec cgi="cgi-bin/skript.cgi"-->
Sagen wir mal, dass das skript nur print "ok"; enthaelt...

Leider gibt mir mein Browser nichts aus, gar nichts...
Und ssi unterstuetzt mein Server, da er da er bei #echo var reagiert...

Wenn irgendetwas fehlerhaft ist, schreibt der browser doch immer an error occured during...
Das ist beim #exec nicht der fall, aber es funzt trotzdem nicht, wieso??

thx

[Der Linke Setzer]

Leider gibt mir mein Browser nichts aus, gar nichts...

</selfaktuell/artikel/schroepl03.htm#a9>

[alex]

Leider gibt mir mein Browser nichts aus, gar nichts...

</selfaktuell/artikel/schroepl03.htm#a9>

Jaja, das Skript besteht nur aus:

#!/usr/bin/perl -w
print "ok";

Da brauch ich keine Diagnose stellen, es laesst sich reibungslos ausfuehren.
Im Zeilenmodus steht "ok", nicht aber im Browser!

Der Uni-Server sollte doch wohl richtig konfiguriert sein,
davon gehe ich aus, also woran scheitert es?
(Bei meinem OmniHTTPd zuhause unter Win funzt es so.)

thx

[Bernhard Peissl]

Grüssi

Jaja, das Skript besteht nur aus:
#!/usr/bin/perl -w
print "ok";
Da brauch ich keine Diagnose stellen, es laesst sich reibungslos ausfuehren.

Falsch gedacht! es fehlt der Header: print "Content-type: text/html\n\n";

Im Zeilenmodus steht "ok", nicht aber im Browser!

Tja, dann probiers mal mit Header!

Der Uni-Server sollte doch wohl richtig konfiguriert sein,
davon gehe ich aus, also woran scheitert es?

wenn ich dir erzähle wie mies unsere Uni-Server konfiguriert sind, da kommt dir das Grauen! Hast du die Möglichkeit über htacces den Server "nachzukonfigurieren" ? Falls ja, les dir die Artikel von Michael durch, falls nicht, und das mit dem Header auch nicht der Fehler war, hat sich das Thema erledigt.

(Bei meinem OmniHTTPd zuhause unter Win funzt es so.)

da "funzt" alles, das ist keine Kunst dort SSI zum laufen zu bringen :-/

lg bernhard

[alex]

Grüssi

Jaja, das Skript besteht nur aus:
#!/usr/bin/perl -w
print "ok";
Da brauch ich keine Diagnose stellen, es laesst sich reibungslos ausfuehren.

Falsch gedacht! es fehlt der Header: print "Content-type: text/html\n\n";

Oh Gott!
Ich krieg die Krise. Ich hatte den Header anfangs drin,
doch der hatte nichts gebracht. Jetzt sehe ich,
dass ich nur ein \n angehaengt habe, kotz...
Da konnte es auch nicht funzen...

(Ich hasse diesen Fehler, hatte ich schonmal.)

Danke, Bernhard.

[alex]

trotzdem merkwuerdig, dass es bei omni unter win
auch ohne klappt.

thx

[Bernhard Peissl]

Grüssi,

trotzdem merkwuerdig, dass es bei omni unter win
auch ohne klappt.

Lass es mich mal so sagen. Der Omni ist das "MS-Word" (obwohl nicht von MS *g*) unter den Webservern ;-)

lg bernhard

[Moldawian]

Hi,

trotzdem merkwuerdig, dass es bei omni unter win
auch ohne klappt.

Lass es mich mal so sagen. Der Omni ist das "MS-Word" (obwohl nicht von MS *g*) unter den Webservern ;-)

Heißt das der Omni ist besonders gut?
MfG :-)
Moldawian

[Carsten]

Hallo Bernhard!

Falsch gedacht! es fehlt der Header: print "Content-type: text/html\n\n";

Das verstehe ich nicht.
Das Script fügt seine Ausgabe doch mitten im HTML ein, dort wo das <!-- ssi goes here  --> steht. Da ist der Header doch schon längst vom Apache -so wie bei statischen Dokumenten auch- ausgegeben worden.

Das Script wird ja in eine HTML-Seite includiert, es ersetzt diese nicht wie sonst üblich, also sollte der Versuch mit der Header-Ausgabe  darin enden, dass man "Content-type: text/html\n\n" lesbar mitten auf seiner Webseite stehen hat.

Gruss,
 Carsten

[Bernhard Peissl]

Grüssi,

Das Script fügt seine Ausgabe doch mitten im HTML ein, dort wo das <!-- ssi goes here  --> steht. Da ist der Header doch schon längst vom Apache -so wie bei statischen Dokumenten auch- ausgegeben worden.

Nein! Was passiert wenn ein Client eine Seite anfordert? Der Apache bekommt den Request, schielt mal kurz auf die Dateiendung, sieht html, und weiss, aha, das hat den Content-type: text/html! Also schmeisst er diese neugewonnene Erkenntnis gleich mal in den Response-Header. Dann macht er sich an die anderen Header, und dann, ganz am Schluss gibt der den Inhalt der angeforderten Seite im Body der Response mit!

Wenn nun ein shtml Dokument angefordert wird sieht der alte Indianer an der Dateiendung, dass er dieses Dokument erst parsen muss, da Inhalte der Seite erst noch (von ihm oder scripts) generiert werden müssen. Dies macht er dann. Das script selbst muss dem Server nun bekanntgeben welches Format der Output des Scripts hat, das kann der Server ja nicht riechen und dieser Content-type dient dem Apache dann dazu, den Content-type der Response zu generieren. Wenn dann das script abgearbeitet ist, und die Seite komplett ist, dann (und da sind die Header schon alle fertig) wird wieder die Seite in den Response-Body eingefügt und abgeschickt!

Ehrlich gesagt bin ich mir aber nicht sicher was passiert wenn ein script in einer shtml-Seite 2 verschiedene Content-types ausgibt. Solange die scripts immer denselben Content-type ausgeben ist ja alles paletti, aber was wenn z.b. text/plain und text/html ausgegeben wird, oder viel schlimmer, einmal text/html und einmal audio/midi oder sowas? Was macht der Server dann? Nimmt er das erste und ignoriert er die zweite? Nimmt er dann den DefaultType? Hängt er sich auf?

Generell: was passiert, wenn mehrere Content-types ausgegeben werden?

lg bernhard

[n.d. parker]

Moin,

Wenn nun ein shtml Dokument angefordert wird sieht der alte Indianer an der Dateiendung, dass er dieses Dokument erst parsen muss, da Inhalte der Seite erst noch (von ihm oder scripts) generiert werden müssen. Dies macht er dann.

und fuegt den Content-type dazu, der in der conf fuer .shtml festgelegt ist (text/html typischerweise)

Das script selbst muss dem Server nun bekanntgeben welches Format der Output des Scripts hat, das kann der Server ja nicht riechen und dieser Content-type dient dem Apache dann dazu, den Content-type der Response zu generieren. Wenn dann das script abgearbeitet ist, und die Seite komplett ist, dann (und da sind die Header schon alle fertig) wird wieder die Seite in den Response-Body eingefügt und abgeschickt!

nein. Das Vorgehen ist anders.
Der Apache (bzw. mod_ssi) fuehrt Subrequests aus, also im Grunde normale HTTP-Requests, *deshalb* muessen Scripte einen Content-type zurueckgeben. Wwas fuer einen, duerfte im Grunde ziemlich Wurst sein (bei text/plain und text/html ist es jedenfalls so, was bei audio/midi passiert - keine Ahnung, duerfte ihn aber auch nicht kratzen)

Viele Gruesse,

n.d.p.

[Carsten]

Hallo alex!

Hi

Ich will einfach mittels ssi ein perl skript starten:
<!--#exec cgi="cgi-bin/skript.cgi"-->

musste da nicht ein Leerzeichen vor das '-->' ? Aber du sagtest ja das andere ssi gehen. Kann es dann sein das exec einfach nicht zulässig ist? Denn damit lässt sich wesentlich mehr Unfug anstellen und es verursacht auch mehr Serverlast als die übrigen ssi-Schnipsel. Frag mal den Server-Admin.

Gruss,
 Carsten

[alex]

Hallo alex!

Hi

Ich will einfach mittels ssi ein perl skript starten:
<!--#exec cgi="cgi-bin/skript.cgi"-->

musste da nicht ein Leerzeichen vor das '-->' ? Aber du sagtest ja das andere ssi gehen. Kann es dann sein das exec einfach nicht zulässig ist? Denn damit lässt sich wesentlich mehr Unfug anstellen und es verursacht auch mehr Serverlast als die übrigen ssi-Schnipsel. Frag mal den Server-Admin.

Man kann also das exec sperren?
Dann werde ich mich mal erkundigen (meine seiten liegen auf der uni...).
Das Leerzeichen hat jedenfalls nichts gebracht.

Trotzdem danke.

[Bernhard Peissl]

Grüssi,

Man kann also das exec sperren?

http://www.teamone.de/selfaktuell/artikel/schroepl02.htm#a6 -- siehe "Options"

Dann werde ich mich mal erkundigen (meine seiten liegen auf der uni...).

Man kann scripts auch mit #include virtual ausführen.

lg bernhard

[Carsten]

Hallo alex!

Man kann also das exec sperren?

Ja:

http://httpd.apache.org/docs/howto/ssi.html#executingcommands

Gruss,
 Carsten