Probleme mit SSI flastmod und LAST_MODIFIED

[Karl-Heinz Bühler]

Hallo,

mein Problem hängt mit den unterschiedlichen Ausgaben von den SSI-Aufrufen <!--#echo var="LAST_MODIFIED" --> und <!--#flastmod virtual="/datei.shtml" --> zusammen.
Kurz zur Erkäuterung, was ich machen will:
Ich habe mehrere shtml-Dateien, die wiederum als einzelne SSI-Schnipsel nacheinander in einer Seite aufgerufen werden
<!--#include virtual="/1.shtml"-->
<!--#include virtual="/2.shtml"-->
<!--#include virtual="/3.shtml"--> usw.

Die einzelnen (Schnipsel)Seiten werden durch einen Automatismus in unregelmäßigen Intervallen mit Inhalten (nur Text) befüllt. Bei der Ausgabe sollen aber nur diejenigen (Schnipsel)Seiten angezeigt werden, die von "heute" oder "gestern" stammen. Ältere Schnipsel sollen durch eine leer.shtml ersetzt werden. Dazu habe ich eine SSI-Prüfroutine geschrieben, die aber noch an Problemen mit LAST_MODIFIED und flastmod scheitert. LAST_MODIFIED läßt sich zwar mittels
<!--#config timefmt="%j" --> und <!--#if expr="$DATE_LOCAL = $LAST_MODIFIED" --> gut prüfen, aber LAST_MODIFIED gibt nicht - wie die üblichen Beschreibungen vermuten lassen - das Datum der letzten Aktualisierung an, sondern nur das Datum, zu dem die Datei erstmals auf dem Server (Apache) angelegt wurde. Spätere Veränderungen werden ignoriert. LAST_MODIFIED bleibt also immer gleich.
<!--#flastmod virtual="/datei.shtml" --> gibt zwar brav den Zeitstempel der letzten Aktualisierung an, läßt sich aber offenbar nicht als Variable (<!-- #set var=...) definieren. Ein Prüfvergleich, z.B. <!--#if expr="$DATE_LOCAL = $flastmod" --> scheint also nicht möglich. Oder irre ich mich da? Zumindest habe ich in den mindestens 99 Dokus (auch apache.org) nichts in der Art gefunden. Hat dazu jemand einen guten Tipp? Helfen würden mir allerings nur SSI-Lösungen. PHP
wird vom Server nicht unterstützt, Perl hilft auch nicht (Kein Zugang zu cgi-bin) und Javascript kommt auch nicht in Frage.

Sorry für den langen Text, aber ich wollte das Problem einigermaßen verständlich darstellen.

danke kalle

[Sönke Tesch]

LAST_MODIFIED gibt nicht - wie die üblichen Beschreibungen vermuten lassen - das Datum der letzten Aktualisierung an, sondern nur das Datum, zu dem die Datei erstmals auf dem Server (Apache) angelegt wurde. Spätere Veränderungen werden ignoriert. LAST_MODIFIED bleibt also immer gleich.

Ich vermute mal, daß der Fehler woanders liegt. Denn mal abgesehen davon, daß es an diesem Ende der Leitung einwandfrei funktioniert, würde es mich wundern, wenn LAST_MODIFIED nicht LAST_MODIFIED ist, sondern CREATED, und obendrein flastmod und LAST_MODIFIED, die ansich auf dieselbe Systemresource zurückgreifen müssten, unterschiedliche Ergebnisse liefern.

Bist Du Dir sicher, daß Du die jeweils richtige Datei zu fassen hast? Was sagen "ls -l" oder Dein FTP-Client dazu, quasi als unabhängige dritte Instanz? Das LAST_MODIFIED den Zeitpunkt der Datei, in der es vorkommt, enhält, ist Dir sicher klar ;)

<!--#flastmod virtual="/datei.shtml" --> gibt zwar brav den Zeitstempel der letzten Aktualisierung an, läßt sich aber offenbar nicht als Variable (<!-- #set var=...) definieren.

Nein, flastmod ist eine Ausgabefunktion, keine Variable.

Gruß,
  soenk.e

[Karl Heinz Bühler]

Hallo Sönke

Du hast tatsächlich recht. Der Fehler liegt woanders.

Ich vermute mal, daß der Fehler woanders liegt. Denn mal abgesehen davon, daß es an diesem Ende der Leitung einwandfrei funktioniert, würde es mich wundern, wenn LAST_MODIFIED nicht LAST_MODIFIED ist, sondern CREATED, und obendrein flastmod und LAST_MODIFIED, die ansich auf dieselbe Systemresource zurückgreifen müssten, unterschiedliche Ergebnisse liefern. ... Das LAST_MODIFIED den Zeitpunkt der Datei, in der es vorkommt, enhält, ist Dir sicher klar.

Gruß,
  soenk.e

Dein letzter Satz hat mich auf die richtige Spur gebracht. Der SSI-Aufruf für LAST_MODIFIED ist zwar in der SSI-(Schnipsel)-Seite eingebunden, wird aber nicht dort ausgeführt. In Wirklichkeit wird der SSI-Schnipsel zuerst in die "Mutterseite" eingebunden und dann erst ausgeführt. D.h. der Wert, der von LAST_MODIFIED ausgegeben wird, bezieht sich nicht auf die Veränderung des eingebundenen Schnipsels, wie ich fälschlicherweise angenommen habe, sondern auf die "Mutterseite", in die der SSI-Schnipsel eingefügt wird. Da sich aber die "Mutterseite" nicht ändert, bleibt auch der Wert von LAST_MODIFIED immer gleich. flastmod dagegen enthält ja den Pfad zu der Unterseite und gibt daher deren Veränderung richtig an. Also: Fehler gefunden, aber noch keine Lösung, da ich ja LAST_MODIFIED von der Unterseite brauche.
Trotzdem vielen Dank.

PS: Finde übrigens das breite Spektrum Deiner Interessensgebiete recht  interessant. Von Kinoseiten für Hamburg bis hin zu Infos über den Erwerb eine Greencard.*g* Nicht wundern! Ist eine Art Berufskankheit (Journalist), dass ich immer mal schnell recherchiere, mit wem ich es zu tun habe. Nix für ungut!

Gruß aus München nach Hamburg

[Sönke Tesch]

Dein letzter Satz hat mich auf die richtige Spur gebracht. Der SSI-Aufruf für LAST_MODIFIED ist zwar in der SSI-(Schnipsel)-Seite eingebunden, wird aber nicht dort ausgeführt. In Wirklichkeit wird der SSI-Schnipsel zuerst in die "Mutterseite" eingebunden und dann erst ausgeführt. D.h. der Wert, der von LAST_MODIFIED ausgegeben wird, bezieht sich nicht auf die Veränderung des eingebundenen Schnipsels, wie ich fälschlicherweise angenommen habe, sondern auf die "Mutterseite", in die der SSI-Schnipsel eingefügt wird.

Das ist so nicht richtig. Alles, was per include virtual importiert wird, wird intern wie ein echter Abruf gehandhabt ("subrequest"). Nur deshalb ist es zum Beispiel auch möglich, CGI-Programme, auch mit URL-Parametern, korrekt in eine SSI-Seite einzubauen - sie werden ausgeführt und das Ergebnis landet in der SSI-Seite, nicht das Programm selber.

Mir ist im nachhinein eingefallen, daß ich mal ein ähnliches Problem hatte. Zwar ging es seinerzeit darum, daß die Mutterdatei als HTTP-Änderungsdatum das aktuellste aller ihrer Einzelteile ausgeben sollte, aber auch da kam als Datum immer nur jenes der Mutterdatei.
Grund war -wenn ich mich recht entsinne-, daß für dieses Attribut, welches sicher auch für die Variable LAST_MODIFIED verwendet wird, immer explizit auf den Datensatz der Hauptanfrage zugegriffen wurde, selbst wenn es sich um einen Subrequest handelte (eine Vergleichslogik, welches Datum neuer ist, fehlte selbstredend auch, tut aber hier nichts zur Sache).

Offensichtlich hast Du jetzt genau dieses Problem; ändern lässt es sich nur durch eine Änderung des Apache-Codes in mod_include.c.

Und ein Blick in die Anleitung sagt's eigentlich auch:

LAST_MODIFIED
    The last modification date of the document requested by the user.

"document _requested_by_the_user_", also das abgerufene Dokument, nicht die eigene Datei. Ist mir auch erst aufgefallen, als ich die Erklärung zu DOCUMENT_URI darüber gelesen habe:

DOCUMENT_URI
    The (%-decoded) URL path of the document requested by the user.
    Note that in the case of nested include files, this is not then
    URL for the current document.

Man beachte den letzten Satz. Ich sollte gelegentlich auch mal in die Anleitung blicken und das nicht immer nur anderen raten ;]

Also: Fehler gefunden, aber noch keine Lösung, da ich ja LAST_MODIFIED von der Unterseite brauche.

Eine möglicherweise frohe Botschaft hätte ich trotzdem noch: Über die Anleitungssachen oben bin ich nur gestolpert, weil ich mich eigentlich vergewissern wollte, ob SSI auch CGI-Variablen anbietet. Da dem tatsächlich der Fall ist, kannst Du vielleicht versuchen, über eine dieser Variablen die aktuelle Datei zu fassen zu kriegen (siehe http://hoohoo.ncsa.uiuc.edu/cgi/env.html).

PS: Finde übrigens das breite Spektrum Deiner Interessensgebiete recht  interessant. Von Kinoseiten für Hamburg bis hin zu Infos über den Erwerb eine Greencard.

Für irgendwas muß man ja sein Geld rauswerfen :)

Gruß,
  soenk.e

[Karl-Heinz Bühler]

Danke für den weiteren Tipp. Werde ihn aber erst demnächst testen können, da ich jetzt erst mal in den Urlaub fahre. Werde mich aber etwa ab ca. 10.6. wieder melden und Dir dann mitteilen, ob es endlich funktioniert.

Gruß Kalle

[Michael Schröpl]

Hi Karl-Heinz,

Helfen würden mir allerings nur SSI-Lösungen. PHP
wird vom Server nicht unterstützt, Perl hilft auch nicht (Kein Zugang zu cgi-bin)

sehr schade.

XSSI wird Deinem Thema nicht wirklich gerecht - die Datumsvergleichlogik, die Du bauen mußt, ist schon ohne das vorliegende Problem relativ kompliziert im Vergleich zu einem entsprechenden Perl- oder PHP-Programm, welches ein Verzeichnis parsen und die entsprechenden Schnipsel viel performanter einbinden würde.
Vom Kosten/Nutzen-Faktor klingt ein Providerwechsel nach einer echten Alternative ...

Oder ... wie sieht es mit dem Ansatz aus, die zu konstruierenden HTML-Dokumente, deren Inhalt sich ja nicht innerhalb eines Tages ändert, statt mit SSI über einen täglich nachts laufenden Prozeß (cron?) statisch aus den Schnipseln zusammenzubauen? Dann hättest Du die Funktionalität von z. B. Perl und wärest nicht auf die Restriktionen von SSI limitiert ...

Viele Grüße
      Michael