Guten Tag! Auf einer SuSE 6.1 laeuft der Apache 1.3.6 und Perl 5.005_02. Ich beobachte folgendes: Das Script in http://.../cgi-bin/prog/start.pl wird in einem Browser korrekt angezeigt, Aenderungen dieses Scriptes wirken sich beim Reload eines Browsers sofort aus. Nun greift start.pl auf ein Unterprogramm eines Moduls im gleichen Verzeichnis zu. Lasse ich das Script auf der Konsole direkt laufen, werden alle Aenderungen des Unterprogrammes sofort im HTML-Ausgabecode beruecksichtigt. Im Browser verhaelt sich das alles aber anders. Entweder es kommt die aktuelle Aenderung, dann kommt wieder der Zustand _vor_ der Aenderung. Das ist rein zufaellig. Also "cached" da jemand und zwar recht "zufaellig". Was mich nachdenklich macht: Das Caching erfolgt nur beim Zugriff auf das Unterprogramm des Moduls, Aenderungen an der Hauptdatei "start.pl" selber werden sofort weitergegeben. Das kann also mit dem Browser-Caching nicht zusammenhaengen, der kriegt ja den komplett fertigen HTML-Code. Experimente mit <META NAME="expires" CONTENT="now"> oder sogar <META NAME="expires" CONTENT="-1d"> korrigieren an der Tatsache auch nichts. Warum die Anfrage in _diese_ Liste gerade hier: Ich weiss nicht, ob ich in Apache oder in Perl oder ueberhaupt am Betriebssystem suchen muss. Mit PHP3 funktioniert die Sache im uebrigen einwandfrei. Dort habe ich solche Sachen noch nicht beobachtet. Weiss jemand Rat? Gruss Peter Blancke -- Nachtwaechter ist der Wahnsinn, weil er wacht... --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Am 11.05.2000, 02:57:54, schrieb Peter Blancke
Guten Tag! Hallo Peter,
Nun greift start.pl auf ein Unterprogramm eines Moduls im gleichen Verzeichnis zu. Lasse ich das Script auf der Konsole direkt laufen, werden alle Aenderungen des Unterprogrammes sofort im HTML-Ausgabecode beruecksichtigt.
Im Browser verhaelt sich das alles aber anders. Entweder es kommt die aktuelle Aenderung, dann kommt wieder der Zustand _vor_ der Aenderung. Das ist rein zufaellig.
Bist Du sicher, dass Du Perl und nicht mod_perl verwendest? Das von Dir beschriebene Phänomen tritt auf, wenn ein Perl Script einen Modul nur mit require referenziert. Um herauszufinden, ob Du mod_perl, oder Perl/CGI verwendest, teste im Script die beiden folgenden Variablen: exists $ENV{"MOD_PERL"} # if running under mod_perl $ENV{"GATEWAY_INTERFACE"} eq "CGI-Perl/1.1" Weitere Informationen findest Du unter perl.apache.org. Dort gibt es auch eine gute Doku, die auf die Unterschiede (es gibt einige!) zwischen mod_perl und Perl/CGI eingeht. Wenn Du das CGI Modul verwendest, empfehle ich Dir diesen wie folgt zu benutzen: use CGI; CGI::_reset_globals; $cg=new CGI; Gruss, Beni --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Thu, 11 May 2000, Benjamin Stocker wrote: Hallo Benjamin! Danke fuer schnelle Reaktion!
Am 11.05.2000, 02:57:54, schrieb Peter Blancke
zum Thema Apache-CGI-Perl: Nun greift start.pl auf ein Unterprogramm eines Moduls im gleichen Verzeichnis zu. Lasse ich das Script auf der Konsole direkt laufen, werden alle Aenderungen des Unterprogrammes sofort im HTML-Ausgabecode beruecksichtigt.
Im Browser verhaelt sich das alles aber anders. Entweder es kommt die aktuelle Aenderung, dann kommt wieder der Zustand _vor_ der Aenderung. Das ist rein zufaellig.
Bist Du sicher, dass Du Perl und nicht mod_perl verwendest? Das von Dir beschriebene Phänomen tritt auf, wenn ein Perl Script einen Modul nur mit require referenziert.
Um herauszufinden, ob Du mod_perl, oder Perl/CGI verwendest, teste im Script die beiden folgenden Variablen:
exists $ENV{"MOD_PERL"} # if running under mod_perl $ENV{"GATEWAY_INTERFACE"} eq "CGI-Perl/1.1"
Die beiden Env-Angaben liefern: MOD_PERL: Env.mod_perl/1.19 GATEWAY_INTERFACE: CGI-Perl/1.1 Hmmm... was ist es dann? Mod_Perl? Perl?
use CGI; CGI::_reset_globals; $cg=new CGI;
Das habe ich probiert. Aendert aber nichts an dem Zustand, dass offensichtlich veraltete Inhalte ausgegeben werden, mitunter auch nicht. Es geht alles nur, wenn ich auf eigene Module im gleichen Verzeichnis verzichte. Aber gerade die Module sollen mir die vielen Wiederholungsaufgaben abnehmen... Noch andere Ideen? Die angegebenen Dokus werden jetzt gleich studiert... Danke! Gruss Peter Blancke -- Nachtwaechter ist der Wahnsinn, weil er wacht... --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Am 11.05.2000, 04:36:18, schrieb Peter Blancke
Die beiden Env-Angaben liefern:
MOD_PERL: Env.mod_perl/1.19 GATEWAY_INTERFACE: CGI-Perl/1.1 Hmmm... was ist es dann? Mod_Perl? Perl?
Du arbeitest mit mod_perl. Wenn die Performance im Moment nicht so
wichtig ist, kannst Du auf Perl/CGI umstellen (/usr/bin/perl), das ist
zwar langsamer, aber Deine Scripts werden dann wieder funktionieren.
Aendere den cgi-bin Abschnitt im httpd.conf so, dass er etwa folgendes
Aussehen hat (stammt aus suse63 default):
ScriptAlias /cgi-bin/ "/usr/local/httpd/cgi-bin/"
On Thu, 11 May 2000, Benjamin Stocker wrote:
Am 11.05.2000, 04:36:18, schrieb Peter Blancke
zum Thema Re: Apache-CGI-Perl: Die beiden Env-Angaben liefern:
MOD_PERL: Env.mod_perl/1.19 GATEWAY_INTERFACE: CGI-Perl/1.1 Hmmm... was ist es dann? Mod_Perl? Perl?
Du arbeitest mit mod_perl.
Aendere den cgi-bin Abschnitt im httpd.conf so, dass er etwa folgendes Aussehen hat (stammt aus suse63 default):
Ja, so sieht es bereits auf der SuSE 6.1 aus. Fuer mich erschwert sich die Sache dadurch, dass ich zwar meine lokale Entwickler-Maschine frei konfigurieren kann, nicht aber die des Providers vom Kunden. Und dort tritt das gleiche Problem auf. Alternative wird wohl werden, dass ich PHP3 einsetze. Das laeuft dort naemlich einwandfrei und ich habe da auch gute Programmiererfahrungen mit. Trotzdem ein bisschen bedauerlich - Perl macht naemlich verdammt viel Spass! Ich bleibe aber trotzdem am Experimentieren. Was spricht eigentlich gegen PHP3? Danke fuer erste Stellungnahmen!
[...] lies auf jeden Fall die beiden Dokumente 'Quick guide' und 'mod_perl_traps', sowie die FAQ aufmerksam durch.
Der sonnige Nachmittag geht im dunklen Kaemmerchen dahin... ;-))
Insbesondere globale Variablen und Module, die mit 'require' geladen werden, verursachen mit Sicherheit Programmfehler (Ich habe's selbst erlebt)!
Und ich erlebe es gerade im Augenblick. Aber alleine eine gleichbleibende Zeile im Fussbereich eines jeden Dokumentes _erneut_ schreiben, kann doch der Weisheit letzter Schluss dann auch nicht sein. So long... Gruss Peter Blancke -- Nachtwaechter ist der Wahnsinn, weil er wacht... --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Peter Blancke (blancke@gmx.de) wrote: PB> Ich bleibe aber trotzdem am Experimentieren. Was spricht eigentlich PB> gegen PHP3? PB> Danke fuer erste Stellungnahmen! Ich würde spontan mal sagen, dass du in PHP keine Module wie in Perl hast und nicht objektorientiert programmieren kannst (okay, das kann man in Perl ja nun auch nicht _wirklich_, aber zumindest in einigen, sehr praktischen, Ansätzen). In PHP ist die Syntax ja quasi gleich Perl, aber es fehlen viele Fähigkeiten, die Perl hat, und einige Sachen. z. B. Datenbankzugriff, vereinfacht wurden - also einfacher zu handhaben aber auch "verstümmelt". In PHP geht der Zugriff auf eine mysql-Datenbank ziemlich einfach, aber wenn das ganze dann plötzlich auf einer ODBC-Datenbank laufen soll, wirds schwierig. Bei Perl/DBI ist das kein Problem. Und da ich professionell Perl-Anwendungen vertreibe, die auf möglichst vielen Servern laufen sollen, ist mir sowas wichtig. Ich benutze PHP gerne mal, um "zwischendurch" ein kleines Script zu machen, z. B., dass der Inhalt eines Formulars in einen Cookie gespeichert werden soll. Dabei ist es dann auch praktisch, dass ich PHP direkt in die Seite "reinbasteln" kann, und nicht erst ein Script extra bauen muss. Aber für größere Anwendungen immer Perl. (Wo wir gerade beim Thema sind, die Cookie-Routine setcookie von PHP funktioniert nicht (zumindest bei mir nie), es kursierte dann im Netz eine MySetCookie Funktion, aber die enthielt auch noch einen Fehler. Wer will, kann die nun funktionierende Cookie-Setz-Funktion bei mir per PM bekommen.) Ich habe mal einem Freund eine ganze Liste gemacht, was Perl kann und PHP nicht ;-) Ich hoffe, ich habe auch durch mein Geschwafel nicht zu sehr gelangweilt *g* -- Andreas Reich - webmaster@cyraxx.de ICQ# 19338732 - http://www.cyraxx.de/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Andreas Reich (webmaster@cyraxx.de) wrote: AR> In PHP ist die Syntax ja quasi gleich Perl, aber es fehlen viele AR> Fähigkeiten, die Perl hat, und einige Sachen. z. B. Datenbankzugriff, AR> vereinfacht wurden - also einfacher zu handhaben aber auch AR> "verstümmelt". Da ist mir wohl die Grammatik aus den Fugen geraten. Korrigierte Version in etwa so: In PHP ist die Syntax ja quasi gleich Perl, aber es fehlen viele Fähigkeiten, die Perl hat, und einige Sachen, z. B. Datenzugriff, sind vereinfacht - sie sind also einfacher zu handhaben aber auch "verstümmelt". -- Andreas Reich - webmaster@cyraxx.de ICQ# 19338732 - http://www.cyraxx.de/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (3)
-
blancke@gmx.de
-
moody@mail.media-plus.ch
-
webmaster@cyraxx.de