Einschließen Dateien sind ausgezeichnete Werkzeuge für das Verwalten des Netzinhalts. FDSE liefert beschränkte Unterstützung für sie.

Als ein Beispiel einschließeder Unterstützung, die "header.htm" Schablone die für jede Sprache verwendet wird einen //SSI// Anruf für inline der Text der "style.inc" Datei.

//SSI// Syntaxanalyse wird mit der PrintTemplate Funktion gemacht.

PrintTemplate versucht die eingeschlossenen Dateien richtig zu behandeln. Weil es über die Angleichungen zwischen URL-Pfaden und Dateien systempfaden uninformiert ist, ist dieser Code ein wenig fehlergefährdet. Jedoch glaube ich, daß es für die Mehrheit von Benutzern funktioniert, und viele Benutzer finden es sehr hilfreich.

Unten sind akzeptable Serverseite einschließen Formate. Diese müssen genau passen - keine Freiheit in whitespace wird erlaubt:

<P>The script was modified on: <!--#echo var="LAST_MODIFIED" -->.</P>
<P>Hello world: <!--#include virtual="file.txt" -->.</P>
<P>Hello world: <!--#include file="file.txt" -->.</P>

Nach Handhabung von "var zurückwerfen" //SSI// Anrufen ist nach der Apachenmod_include Spezifikation modelliert; sehen http://www.apache.org/docs/mod/mod_include.html.

Vars unterstützt DATE_GMT, DATE_LOCAL, LAST_MODIFIED, DOCUMENT_URI, DOCUMENT_NAME und alle Standardumgebungsvariablen (SERVER_SOFTWARE, HTTP_USER_AGENT, HTTP_REFERER, REMOTE_ADDR, usw.)

Die letzteren zwei Beispiele zeigen an, daß der Benutzer den //SSI// Anruf durch den wörtlichen Inhalt von "file.txt" ersetzen will. Lassen Sie uns sagen, daß unser gegenwärtiges Arbeitsverzeichnis ist, ". /searchdata "(oder welcher $ auch immer DataFilesDir ist), und die Sprache ist auf "Englisch" gestellt. Wir suchen nach der Datei "file.txt" in dieser Bestellung:

	"./searchdata/templates/english/file.txt"
	"./searchdata/templates/english/../file.txt"
	"./searchdata/templates/english/../../file.txt"
	"./searchdata/templates/english/../../../file.txt"
	"./searchdata/templates/english/../../../../file.txt"
	...

Bis zu 12 Elternteilpfade werden durchsucht. Beachten Sie, daß dies äquivalent zu suchen ist:

	"./searchdata/templates/english/file.txt"
	"./searchdata/templates/file.txt"
	"./searchdata/file.txt"
	"./file.txt"
	"../file.txt"
	...

Wenn "file.txt" gefunden wurde wird der Inhalt gelesen und in das Dokument eingeführt von wo aus der //SSI// Anruf war und der Suchprozeß bis dahin stehenbleibt. Der Textinhalt wird auch rekursiv nach //SSI// Anrufen gesucht, und PrintTemplate wird Versuchen jene ebensogut zu lösen? Jedes % replace_values wird auch behandelt.

Es gibt das Risiko der Unendlichkeit d.h. wickelt "foo.txt "einschließt" bar.txt", das "foo.txt" einschließt, das "bar.txt" einschließt, welches ..., um dieses zu vermeiden, wenn PrintTemplate hat schon eingeschlossen feilen benanntes "file.txt" ein bißchen, dann es schließt nicht noch eins mit dem Namen "file.txt" ein, obwohl sie in verschiedenen Verzeichnissen sein können. Dies ist weil PrintTemplate ist im allgemeinen uninformiert davon ist eigener absoluter Pfad, und, so daß es den absoluten Pfad von der ZielDatei nicht lösen kann und da es nie riskieren will, dieselbe Datei zweimal einzuschließenbleibt es auf der vorsichtigen Seite.

//SSI// Syntaxanalyse schlägt unter diesen Szenarien fehl:

• Als eine Sicherheitsvorsichtsmaßnahme muß jede eingeschlossene Datei eine Erweiterung haben, und die Erweiterung muß eins sein: (txt | htm | html | shtml | stm | inc). Zu versuchen, jede andere Datei wie "/etc/passwd" oder "passwords.asp" einzuschließen, scheitert mit einem Fehler. Dies ist eine unglückselige Meinungsverschiedenheit zwischen dem Verhalten von PrintTemplate und der mod_include Spezifikation.

• //SSI// Elemente wie "config", "exec", "fsize", "flastmod", "printenv", "set" werden ignoriert (andere Filter können sie ausführen). "include" and "echo" werden nur ausgeführt.

• Schließt ein einzuschließenden physischen Dateiinhalt, nicht die HTTP-Ausgabe der Datei. Dies ist eine unglückselige Meinungsverschiedenheit zwischen dem Verhalten von PrintTemplate und der mod_include Spezifikation. Auf diese Art könnten einige Benutzer <--#include virtual="/ads.stm" -->, um die HTML von einer Anzeige, aber stattdessen ihm einzuschließen, schließt den Quellencode vom "ads.stm" Programm ein. Dank den Text-/html Dateien erweiterungsbeschränkungen oben sollte dies höchstens zu Ärger statt einem Sicherheitsbruch führen.

• Wenn $ DataFilesDir irgendwo außerhalb von Ihrem Hauptnetzverzeichnis liegt schlagen Versuche fehl Dateien in Ihr Hauptnetzverzeichnis einzubeziehen.Eine Suche findet nur in den Ordner $ DataFilesDir und direkt darüber ein.

• Auf einer verwandten Notiz schließt ein wird Fehlschlag, wenn der URL-Pfad einen im wesentlichen anderen Namen als es zugrundeliegend ist Systempfad feilen läßt. Zum Beispiel <--#include virtual="/cgi-bin/foo.cgi" --> schlägt fehl wenn der Web-Server bildet ab " "/cgi-bin/" to "e:\webroot\bin" . Der Unterschied zwischen wörtlichem Ordner nennt "cgi-bin" and "bin" verhindert jede Form "../../cgi-bin/foo.cgi" from mapping to "~/bin/foo.cgi". Netzautoren die diesen Syntax verstehen können sich leicht rund um gut durcharbeiten und Ihre Erklärungen anpassen.

• Im Gegensatz zu der Web-Server-Software PrintTemplate löst immer Pfade verglichen mit ihm ist eigenes gegenwärtiges Arbeitsverzeichnis mit Hilfe des obengenannten Algorithmus statt zu vergleichen mit einschließen Datei die syntaktisch analysiert wird. Dies ist eine unglückselige Meinungsverschiedenheit zwischen dem Verhalten von PrintTemplate und der mod_include Spezifikation. Auf diese Art wenn ein Benutzer "/foo/bar.txt" einschließt, und dann bar.txt enthält ein einschließen von "abc.txt" PrintTemplate beginnt die Suche nach "abc.txt" zurück in ". /searchdata/templates /Englisch/", statt in derselben subfolder wo "bar.txt" herausgefunden wurde. Es ist wahrscheinlich das PrintTemplate macht die tatsächliche Datei "abc.txt" nie in diesem Szenario ausfindig, weil es jetzt über die Tatsache, daß es in subfolder"/foo/" nachsehen muß nicht informiert ist.

• Auf Systemen, wo $ 0 ein basename anstatt einem absoluten Pfad zurückgibt, schlägt "Echo var" von LAST_MODIFIED und DOCUMENT_URI wahrscheinlich fehl.

Diese Ausfälle ergeben sich, weil:

• dieser Perl Schrift die Information über den eigenen absoluter Pfad fehlt

• diese Perl Schrift ist über die virtuellen Pfad Pfadangleichungen vom Web-Server uninformiert

• diese Schrift ist über dateinamenausführbare Angleichungen vom Web-Server uninformiert und kann in jedem Fall nicht aus Realms Privilegien privileges/power ausführen.

Diese Gründe sind grundsätzlich und können (im allgemeinen) nicht mit gegenwärtiger Software überwunden werden. Die einzige Art, dieses zu überwinden, soll CGI-Ausführung laufen lassen unter Einschließung zu verarbeiten Filtern. Gegenwärtig scheinen Web-Server an Inhalt entwederan den einschließenden Parser oder zum Perl Parserzu senden, jedoch nicht an beide.