Seitenaufruf über CGI / SHELL

[stk]

Hallo zusammen,

ich habe ein kleines Problem mit mit einem Seitenaufruf via Shell Script.

Zur Vorgehensweise:

Ich schreibe einige Parameter mit Hilfe eines Submit Buttons in eine config.ini Datei.
Zusätzlich rufe ich ein cgi-File auf um die Seite neu zu laden, dies funktioniert soweit auch ganz gut.
Das Problem ist allerdings das die Seite mit den alten Werten geladen wird.
Es werden auch alle Javascriptanweisungen nicht bearbeitet.
Erst wenn ich die Seite nochmal aktualisiere bekomme ich die aktuellen Werte.

Ich habe auch schon versucht das Laden aus dem Cache mit Hilfe von Meta-Befehlen zu vemeiden, leider ohne Erfolg.

Hat evtl. noch jemand eine Idee für mich?

Hier mein shell-Script:
(mipx -pconf  schreibt mir die Variablen aus der "config.ini" in die Felder der "config-license" Seite)

#!/bin/sh

echo "Content-type: text/html"
echo ""
if [ -e /home/mipx ]; then
/home/mipx -pconf "/home/config.ini" "/var/www/config-license.htm"

Danke für eure Antworten

[Jörg Reinholz]

Nun ja. Du sendets ziemlich unvollständige HTTP-Header. Die Meta-Angaben werden nur beachtet, wenn die Seite lokal aus dem Dateisystem geladen wurde.

#!/bin/sh
echo "Cache-Control: no-cache,no-store, max-age=0";
echo "Content-Type: text/html; charset=utf-8"
echo "";

Jörg Reinholz

[stk]

Nun ja. Du sendets ziemlich unvollständige HTTP-Header. Die Meta-Angaben werden nur beachtet, wenn die Seite lokal aus dem Dateisystem geladen wurde.

#!/bin/sh
echo "Cache-Control: no-cache,no-store, max-age=0";
echo "Content-Type: text/html; charset=utf-8"
echo "";

Jörg Reinholz

Danke für die Antwort.
Allerdings hat es nicht zum gewünschten Erfolg geführt.
Es werden immer noch die alten Einträge angezeigt und mein Javascript Code wird immer noch nicht abgearbeitet.

[Jens Holzkämper]

Tach,

Es werden immer noch die alten Einträge angezeigt

tja, wie wäre es mit einem Onlinebeispiel, damit man sich ansehen kann, was das verursacht?

und mein Javascript Code wird immer noch nicht abgearbeitet.

Ich sehe in deinem Code kein Javascript, also kann man dir da vermutlich nicht weiterhelfen, ohne dass du mehr Information lieferst.

mfg
Woodfighter

[stk]

okay, das mit dem Javascript Code war ein wenig missverständlich ausgedrückt. Sorry.
Wenn die Seite normal, nicht über den Shell-Code aufgerufen wird, funktioniert der Code, d.h. es geht nicht um die grundsätzliche Funktion. Deshalb hab ich ihn nicht hinzugefügt.

Dadurch das der Skript-Code nicht abgearbeitet wird, vermute ich, dass die Seite immer noch aus dem Cache geladen wird.
Aber vielleicht liegt das Problem auch nicht am Cache.

Ein Onlinebeispiel stellt sich ein wenig schwierig dar, zumindest für einen fast Laien wie mich.

Im groben Zusammengefasst:
Die Html Seite ( mit Javascript) macht keine Probleme beim normalen Aufruf.
Nur wenn ich mit dem oben genannten Shell Skript die Seite aufrufe werden die alten Werte in die Felder geladen. Nach Aktualisierung der Seite passen die Werte wieder.

Der mipx-Task (siehe Shell-Skript) übernimmt das suchen und eintragen der jeweiligen config.ini Einträge. (funktioniert einwandfrei)

[Der Martin]

Hallo,

okay, das mit dem Javascript Code war ein wenig missverständlich ausgedrückt. Sorry.
Wenn die Seite normal, nicht über den Shell-Code aufgerufen wird, funktioniert der Code

auch das ist jetzt sehr missverständlich. Der aufrufende Client "weiß" doch nichts davon, dass er ein CGI anstößt, das am Server von der Shell bedient wird. Er ruft eine HTTP-Ressource auf und bekommt irgendwas geliefert. Ob das aus einer statischen Datei kommt oder dynamisch von einem CGI generiert wird, oder ob der Server-Admin das mal schnell in die Konsole tippt, kann er nicht wissen.

Also was genau meinst du mit dem obigen Satz? Welche zwei Szenarien vergleichst du da?

Dadurch das der Skript-Code nicht abgearbeitet wird, vermute ich, dass die Seite immer noch aus dem Cache geladen wird.
Aber vielleicht liegt das Problem auch nicht am Cache.

Eben. Denn das Ausführen von Javascript-Code im Dokument ist unabhängig davon, ob das Dokument aus dem Cache kommt oder frisch vom Server angefordert wird. Lediglich das onload-Event wird bei manchen Browsern nicht getriggert, wenn die Information aus dem Cache kommt.

Im groben Zusammengefasst:
Die Html Seite ( mit Javascript) macht keine Probleme beim normalen Aufruf.
Nur wenn ich mit dem oben genannten Shell Skript die Seite aufrufe ...

Nein. Nach deiner bisherigen Beschreibung rufst du die Seite nicht über ein Shellscript auf, sondern der Seitenaufruf durch den Client bewirkt die Ausführung eines Shellscripts. Also genau andersrum. - Oder deine Beschreibung ist so irreführend, dass ich es falsch verstanden habe.

So long,
 Martin

[stk]

Vielen Dank für eure Mühen.
Ich entschuldige mich für die Kopfschmerzen die Ihr wegen meiner laienhaften Erklärung hattet.

Mittlerweile hat sich rausgestellt das es mit dem mipx-Task zu tun hat. Mein Kollege hat mir hier erst die alten Werte übergeben und danach die neuen in das config.ini File geschrieben...
Das ist dann wohl eher die falsche Reihenfolge...

Sorry nochmal.

[Jörg Reinholz]

okay, das mit dem Javascript Code war ein wenig missverständlich ausgedrückt. Sorry.
Wenn die Seite normal, nicht über den Shell-Code aufgerufen wird, funktioniert der Code, d.h. es geht nicht um die grundsätzliche Funktion. Deshalb hab ich ihn nicht hinzugefügt.

Dadurch das der Skript-Code nicht abgearbeitet wird, vermute ich, dass die Seite immer noch aus dem Cache geladen wird.
Aber vielleicht liegt das Problem auch nicht am Cache.

Ein Onlinebeispiel stellt sich ein wenig schwierig dar, zumindest für einen fast Laien wie mich.

Im groben Zusammengefasst:
Die Html Seite ( mit Javascript) macht keine Probleme beim normalen Aufruf.
Nur wenn ich mit dem oben genannten Shell Skript die Seite aufrufe werden die alten Werte in die Felder geladen. Nach Aktualisierung der Seite passen die Werte wieder.

Der mipx-Task (siehe Shell-Skript) übernimmt das suchen und eintragen der jeweiligen config.ini Einträge. (funktioniert einwandfrei)

Ich stückele das jetzt mal mühselig zusammen.

Du hast einerseits ein SHELL-SKRIPT:
/home/mipx

weiter eine statische WEBSEITE:
"/var/www/config-license.htm"

zudem das CGI-SKRIPT mit dem Inhalt:

#!/bin/sh  
echo "Cache-Control: no-cache,no-store, max-age=0";  
echo "Content-Type: text/html; charset=utf-8"  
echo "";  
if [ -e /home/mipx ]; then  
/home/mipx -pconf "/home/config.ini" "/var/www/config-license.htm"  
  

und außerdem noch eine KONFIGURATIONSDATEI:
/home/config.ini

Ziel ist wohl, dass beim Aufruf des CGI-SKRIPTES dieses das SHELL-SKRIPT aufruft, welches aus der den Daten der KONFIGURATIONSDATEI eine neue statische WEBSEITE erzeugt. Mehr war Deiner Beschreibung nicht zu entnehmen.

Wenn, wie Du darlegst, das SHELL-SKRIPT funktioniert, dann muss natürlich die WEBSEITE vom Browser neu abgeholt werden, denn bekommt von der Änderung so viel mit wie Du, wenn Indien ein Sack Tee umfällt. Das SHELL-SKRIPT ist für uns eine Black-Box. Es kann sein, dass daran jeder Hilfversuch scheitern muss, nämlich dann, wenn in der Käfer krabbeln.

Was passiert, wenn Du das CGI-Skript ausführst wissen wir gar nicht. Wir wissen, was zum Teil passieren könnte. Aber nicht, was auf die Abarbeitung des  SHELL-SKRIPTes folgt.

Wenn, wie Du darlegst, das SHELL-SKRIPT funktioniert, sollten aber in jedem Fall nach der tatsächlichen Aktualisierung der WEBSEITE im Browser die neuen Daten auch sichtbar werden. Holt der Browser die WEBSEITE neu ab oder nimmt er die aus dem Cache?

Fehlerquellen:

Gibt denn Dein CGI-Skript irgend etwas aus? Ich sehe nämlich von hier: Es ist nicht vollständig. Da fehlt schon das fi am Ende des IF-Konstruktes. Alle Pfadnamen sehen richtig beschissen aus und sind nicht glaubwürdig.

Die Rechte.
--- Darf denn der Webserver(!) /home/mipx überhaupt ausführen?
--- Hat denn der Webserver das Schreibrecht an /var/www/config-license.htm

• oder verwendest Du außerdem noch setuid- Geschichten?

Cache:

Zweimal Browser - zweimal Cache, zweimal siehst Du nicht, was passiert ist, sondern was irgend wann mal war. Ideal für Kopfschmerzfetischisten!!!

Jetzt ist es Dein Job das zu lesen, zu prüfen und eine nachvollziehbare Beschreibung des "Fehlers" zu verfertigen, die am besten die BEGRIFFE

SHELL-SKRIPT             /home/mipx
CGI-SKRIPT               (Position unbekannt)
KONFIGURATIONSDATEI      /home/config.ini
WEBSEITE                 /var/www/config-license.htm

verwendet statt auch uns nur noch mehr zu verwirren. Das ist nämlich alles ganz schön "durch die Brust ins Auge" (auch "historisch gewachsen") genannt.

Wir wollen GENAU wissen, was die Dateien

SHELL-SKRIPT             /home/mipx
CGI-SKRIPT               (Position ###NOCH### unbekannt)
KONFIGURATIONSDATEI      /home/config.ini
WEBSEITE                 /var/www/config-license.htm

für Rechte "haben".

getfacl /home/mipx zeigt die für /home/mipx. Die anderen wollen wir aber auch!

Unter welchem Benutzer läuft Dein Webserver?

Was steht in der CGI-Datei WIRKLICH.

Und wir wollen GENAU wissen, was von wem wie aufgerufen wurde und was das Resultat war- und zwar nicht die im Browser zu sehende Vermutung, sondern in der statischen WEBSEITE. Auch Deine Beschreibungen dazu waren "ideal für Kopfschmerzfetischisten".

Vermutlich fällt Dir dabei, wenn Du gerade SCHRITT FÜR SCHRITT die Funktionen durchgehst um uns eine aussagefähige Fehlerbeschreibung zu geben, auch der konkrete Fehler auf und somit die Lösung ein.

Ohne die verlangten Daten, vollständige Skripte und ohne eine brauchbare Problembeschreibung können wir nur zur Filzbrille raten. Dann wird das Problem wenigstens nicht mehr sichtbar. Es gibt sehr viele, die sind mit solchen Lösungen zufrieden sind. (Zuletzt sogar die berühmte japanische Atomaufsicht!)

Jörg Reinholz

[Jörg Reinholz]

Es werden immer noch die alten Einträge angezeigt

Dein Browser ist doof. Allerdings ist das richtig, weil dafür ist er auch schnell.

Du darfst deutlich langsamer sein, dafür wird von Dir die Anwendung von Intelligenz erwartet.

Diese Anwendung von Intelligenz sollte dich auf die Idee bringen:

• Browsercache löschen
• tatsächlich gesendete(genauer: empfangene) http-header mit passendem Tool überprüfen (ich nehme dazu wget -d --delete-after http://...)

und mein Javascript Code wird immer noch nicht abgearbeitet.

Was, bitte, weiß ich denn über Dein Javascript? Aber wir sind beim Schritt 1.

Jörg Reinholz