Der Einsatz von SSI wird übrigens damit belohnt, dass die Formatierung der Zeitangabe flexibler ist. Das weiter oben genannte Javascript gibt die Zeit nämlich im Standard-Format aus, was nur mit einem aufwändigen Zusatz-Skript änderbar ist. SSI dagegen erlaubt durch einfache Definition des Zeit-Formats (config timefmt=...) bereits recht viele Möglichkeiten.
 
Standard-Format:

Statt der eigentlich gewünschten UpLoad-Zeit wird hier durch das Parsen fälschlicherweise die aktuelle Uhrzeit angezeigt. (Die obige Darstellung entspricht genau dem, was man mit Javascript sehen würde, wurde aber, damit es an dieser Stelle auch bei evtl. deaktiviertem Javascript sichtbar ist, dennoch mit SSI gemacht.)
 
SSI-Beispiele:
Hier wird die korrekte UpLoad-Zeit angezeigt.

 
Der Vollständigkeit halber sollte vielleicht noch erwähnt werden, dass per SSI der komplette Inhalt der eingebundenen Datei in die einbindende Seite integriert wird, wogegen beim I-Frame die eingebundene Datei als eigenständige Internet-Seite dargestellt wird.
 
Dies ist wichtig zu wissen, denn wenn die eingebundene Datei zum Beispiel eigene head-Angaben enthält, kann es beim SSI-include-Befehl zu Konflikten mit den head-Angaben der einbindenden Datei kommen.
 
Lässt man dagegen die head-Angaben einfach weg, so werden die Dateien aber innerhalb von I-Frames nicht wirklich korrekt dargestellt. Das stört zwar nicht sonderlich, sofern es lediglich als Hilfe für die offline-Bearbeitung verwendet wird, doch auch das lässt sich auf dem oben beschrieben Weg umgehen:
 
Man umschließt den head-Bereich der eingebundenen Datei ebenfalls mit einer Datums-Abfrage in der Vergangenheit. Somit wird dieser Teil ebenfalls nur offline ausgeführt. Eine eingebundene Datei könnte dann so aussehen:
   
Der letzte Teil ist erforderlich, um die HTML- und body-Bereiche korrekt abzuschließen.
 

 
Beispiel: Eine Kombination 'mit Allem' habe ich übrigens für meine Download-Seiten geschrieben. (Da meine Skripte ständig in Arbeit sind, entsprechen die aktuellen Download-Seiten eventuell zwar ganz oder teilweise nicht mehr den folgenden Beschreibungen, doch sie hatten auf jeden Fall so funktioniert.)
 
Wenn mein Download-Menü von einer anderen meiner Seiten aufgerufen wird, dann enthält es zunächst statt der eigentlichen Menü-Leiste einen Hinweis auf den Disclaimer mit der Option diesen zu akzeptieren oder abzulehnen. Die Download-Seite im Haupt-Fenster enthält zu diesem Zeitpunkt noch an Stelle der Download-Schalter einen Hinweis auf den Disclaimer.
 
Durch Akzeptieren des Disclaimers wird die Menü-Seite erneut geladen und zeigt dann statt der Abfrage der Akzeptanz die eigentliche Menü-Leiste an. Auch die Download-Seite im Haupt-Fenster wird neu geladen und enthält dann die gewünschten Download-Schalter.
 
Bei Ablehnung des Disclaimers wird die Download-Seite weiterhin ohne Download-Schalter angeboten.
 
Okay, das ist sicherlich ein recht komplexer Weg, der kaum Fehler verzeiht. Doch dieser Internet-Bereich ist ja nicht zuletzt mein Experimentier-Feld, um Neues auszuprobieren. Und was selbst komplex funktioniert, das dürfte im Kleinen erst recht gehen. ;o)
 

 
Wenn eine Interent-Seite, die zu einem Frameset gehört, einzeln aufgerufen wird (zum Beispiel durch eine Suchmaschine oder durch sonstige Verlinkung), dann hat man das Problem, dass sie ohne das zugehörige Frameset erscheint, in dem sich Navigation, Titelleiste und andere mehr oder weniger wichtige Elemente befinden. Die einzige konsequente Lösung: Das Frameset muss nachgeladen werden.
 
Hier kann Javascript zwar gute Dienste leisten, doch funktioniert das halt nur, wenn im Browser Javascript nicht deaktiviert ist.
Es geht aber auch mit SSI, was den Vorteil hat, dass es nicht auf den Browser angewiesen ist.
 

 
Statt in den Header jeder einzelnen HTML-Seite, schreibe ich es allerdings in eine eigene Datei, die ich per SSI-Include-Anweisung im Header jeder HTML-Seite aufrufe.
 
Das hat mehrere Vorteile:
1. Das Skript muss nur ein einziges Mal geschrieben werden, wodurch es änderungsfreundlich ist und zudem Speicherplatz spart.
2. Da SSI lokal ohnehin nicht ausgeführt wird, vermeidet man damit Fehlfunktionen des Browsers.
3. Die Einzelseiten können lokal auch ohne Frameset betrachtet werden und lassen sich dadurch mitunter komfortabler bearbeiten.
 

 
Die bereits beschriebene Methode, per SSI ein Frameset nachzuladen, birgt noch den Nachteil, dass das nachgeladene Frameset in der Regel noch nicht die ursprünglich aufgerufene Seite enthält. Hier bedarf es einer Ergänzung des bereits bekannten Skriptes, als auch eine Erweiterung der Frameset-Datei.
 

 
Info für Perfektionisten...
 
Das oben beschriebene Skript hat einen kleinen Schönheitsfehler: Wenn das Frameset lokal, also in der Regel ohne SSI-Unterstützung, aufgerufen wird, dann "sieht" es beide Frame-Aufrufe, also sowohl den für die Startseite als auch den mit dem übergebenen Parameter. Mit letzterem kann das Skript aber lokal nichts anfangen!
 
Dies nur als Information. Einen gravierenden Nachteil sehe ich darin allerdings nicht, da die meisten Browser damit keine Probleme haben. Daher sehe ich auch keine zwingende Notwendigkeit, diesen Fehler abzufangen, was zwar durchaus machbar wäre, aber die Skripte meines Erachtens nur unnötig komplex machen würde.
 
Übrigens...
 
Sollte wider Erwarten das Frameset mal mit einem anderen Parameter, also keinem existierenden Dateinamen, aufgerufen werden (warum auch immer Jemand das tun sollte), so ist auch das kein Beinbruch. Es wird dann innerhalb des Framesets an Stelle der Startseite die übliche Fehlermeldung ausgegeben, dass die gewünschte Datei nicht existiert - und das ist ja auch völlig korrekt. Da die anderen Frames davon nicht betroffen sind, kann der Besucher problemlos per Menü eine existierende Seite anwählen.