PHP & SSI

[Alexander, W.]

Hallo,

habe einen Projekt hinter sich. Die Seiten werden auf Basis von Templates aufgebaut, die SSI beinhalten. Also SSI Befehle innerhalb von Templates.

Leider werden diese SSIs einfach ignoriert.
Kennt jemand die Lösung?

Gruss. A.W.

[Thomas Luethi]

Hallo,

Leider werden diese SSIs einfach ignoriert.
Kennt jemand die Lösung?

Eine Datei kann (normalerweise) nur _entweder_ auf PHP
_oder_ auf SSI geparst werden.
Ein Mixen der beiden Technologien ist IMHO meist nicht sinnvoll
und funktioniert - wenn ueberhaupt - am ehesten mit
verschachtelten Includes.

Du hast Dein Problem leider nicht sehr ausfuehrlich beschrieben.
Wie heissen die Dateien?
Welche Datei will welche andere(n) Datei(en)
mit welcher Technologie einbetten?

Allenfalls koenntest Du mit PHP bei include() oder readfile() u.s.w.
den Pfad inklusive "http://" angeben, dann wird die Datei
beim Webserver abgeholt (und nicht direkt beim Dateisystem).

Gruesse,

Thomas

[Andreas Görtz]

Hi,

Ein Mixen der beiden Technologien ist IMHO meist nicht sinnvoll...

Sehe ich auch so.

...und funktioniert - wenn ueberhaupt - am ehesten mit
verschachtelten Includes.

Werden nicht Dateien, die mit virtual() eingebunden werden, geparst? Das müsste doch dann auch mit Dateien funktionieren, die SSI beinhalten!?

Gruß,
Andreas.

[Thomas Luethi]

Hallo,

Werden nicht Dateien, die mit virtual() eingebunden werden, geparst?

Ja, vermutlich. virtual() habe ich noch nie benutzt. Manual:
http://www.php.net/manual/de/function.virtual.php

Alexander hat leider gar nicht beschrieben,
wie sein Template-Gebastel aussieht, aber
vielleicht ist virtual() eine Loesung fuer ihn...

mfg, Thomas

[at]

Hallo.

Eine Datei kann (normalerweise) nur _entweder_ auf PHP
_oder_ auf SSI geparst werden.
Ein Mixen der beiden Technologien ist IMHO meist nicht sinnvoll
und funktioniert - wenn ueberhaupt - am ehesten mit
verschachtelten Includes.

Ist es also unklug oder gar unmöglich, meine vollständig SSI-basierte Präsentation mit einer PHP-Zufallsfunktion auf der Startseite zu versehen? Welche Gefahren oder Unzulänglichkeiten bestehen und wie könnte die Alternative aussehen?
MfG, at

[Thomas Luethi]

Hallo at,

Ein Mixen der beiden Technologien [PHP + SSI]
ist IMHO meist nicht sinnvoll

Ist es also unklug oder gar unmöglich, meine vollständig SSI-basierte Präsentation mit einer PHP-Zufallsfunktion auf der Startseite zu versehen?

Was meinst Du ganz konkret?
Als Startseite z.B. eine "index.php", die rein mit PHP funktioniert?
Alle uebrigens Seiten mit Dateinamen auf ".shtml" oder ".html",
in denen nur SSI vorkommt?
Da sehe ich im Prinzip kein Problem.

Problematisch wird es, wenn man in ein und derselben Datei
beide Dinge mischen will. Z.B. so:

Beispiel 1:
index.php bindet per PHP-Befehl include() oder virtual()
das erste Include kopfzeile.shtml ein.
Dieses seinerseits bindet per SSI-Befehl ein oder mehrere
weitere Dateien ein, z.B. statische HTML-Dateien logo.html
und navigation.html

Beispiel 2:
index.shtml bindet per SSI-Befehl das erste Include
kopfzeile.php ein.
Dieses seinerseits bindet per PHP-Befehl weitere Dateien
ein, z.B. statische HTML-Dateien.

Beides _kann_ zwar auf gewissen Servern funktionieren,
auf andern aber eben auch nicht.

Beispiel 2 ist z.B. auf dem Webserver der Uni Zuerich
"aus Sicherheitsgruenden" nicht moeglich, waehrend
Beispiel 1 offenbar laufen sollte.
http://www.id.unizh.ch/services/koord/www/webmoderator_l/msg00038.html

---

Probleme (z.B. dass Du den Ueberblick verlierst)
duerften sich bei Dir hoechstens ergeben, wenn
*.html-Dateien in einem Verzeichnis auf PHP
und in einem anderen Verzeichnis auf SSI geparst
werden sollen

Solange Du weisst, was Du tust, darfst Du aber
ruhig "mixen"... ;-)

Gruesse,

Thomas

[at]

Hallo.

Was meinst Du ganz konkret?

Der Reihe nach:

• Meine Seiten setzen sich aus mehreren Teilen zusammen.
• Alle wiederkehrenden Teile (Signet, Navigation etc.) werden mittels SSI eingebunden.
• Geplant ist eine Titelseite -- keine Tunnelseite.
• Auch die Titelseite soll die wiederkehrenden Teile enthalten.
• Die Titelseite soll _einen_ Verweis auf _eine_ von mehreren Unterseiten (n Beispiele, n News) enthalten.
• Dieser eine Verweis auf der Titelseite soll zufällig ausgewählt werden.
• Für eine zufällige Auswahl ist mir keine SSI-Funktion geläufig.
• Wie eine zufällige Auswahl mittels PHP zu realisieren ist, weiß ich.
  Folgerichtig lautet mein Plan, diesen einen speziellen zufälligen Verweis mittels PHP umzusetzen, die SSI-Teile aber beizubehalten. SSI und PHP werden aber nicht ineinander verschachtelt.
  Ich hoffe, nun ist es klarer.

Solange Du weisst, was Du tust, darfst Du aber
ruhig "mixen"... ;-)

Ich _meine_ zu wissen, was ich tue, frage aber doch lieber nach.
Und da ich gerade dabei bin: Eine von einem PHP-Skript _aufgerufene_ Seite (Empfangsbestätigung für ein Kontaktformular) kann doch auch SSI in der oben beschriebenen Weise enthalten, oder?
MfG, at

[Thomas Luethi]

Hallo,

• Alle wiederkehrenden Teile (Signet, Navigation etc.) werden mittels SSI eingebunden.

Sind die "Teile" an sich statische HTML-Bloecke?
Oder hast Du darin auch noch mal SSI-Befehle?

• Auch die Titelseite soll die wiederkehrenden Teile enthalten.

Wenn es sich um statische HTML-Bloecke handelt, kannst Du sie ja
problemlos mit PHP statt mit SSI einbinden.
Dann ist IMHO die Funktion readfile() am besten geeignet.

• Für eine zufällige Auswahl ist mir keine SSI-Funktion geläufig.

http://www.google.com/search?q=random+ssi
findet als ersten Treffer:
http://www.stanford.edu/leland/ssi/randssi.shtml
Die Jungs von Stanford haben da offenbar etwas nettes gebastelt,
aber sie erklaeren leider nicht, _wie_. ;-(

Vielleicht findest Du ja unter den uebrigen Treffern
einen gute Loesungsansatz...

Ein Beispiel, wie man abhaengig von der Systemzeit
verschiedene Strings ausgibt, gibt es hier:
http://www.tek-tips.com/gfaqs.cfm/lev2/3/lev3/22/pid/65/fid/3700
Ist natuerlich keine "echte" Zufallsfunktion, aber
ein guter Anfang...

Folgerichtig lautet mein Plan, diesen einen speziellen zufälligen Verweis mittels PHP umzusetzen, die SSI-Teile aber beizubehalten.

Mit welcher Technologie soll das Skript als ganzes geparst werden?
Du musst Dich AFAIK fuer eine Technologie entscheiden...
Vermutlich fuer PHP, da Du ja fuer die Zufallsfunktion
darauf angewiesen bist.

SSI und PHP werden aber nicht ineinander verschachtelt.

Wenn Du das Skript als ganzes mit PHP realisierst und
nur statische HTML-Bloecke einbindest, dann ist wirklich
nur eine Technologie im Spiel, und die Loesung ist IMHO
"sauber" und "stabil" - auch bei Serverwechsel.

Wenn Du aber in den eingebetteten "Teilen" (Includes)
ihrereseits noch SSI-Befehle hast, dann hast Du eben
einen Mix der Technologien - was auf dem einen oder
andern Server zu Problemen fuehren duerfte.

Ich _meine_ zu wissen, was ich tue, frage aber doch lieber nach.

Gute Idee...

Und da ich gerade dabei bin: Eine von einem PHP-Skript _aufgerufene_ Seite (Empfangsbestätigung für ein Kontaktformular) kann doch auch SSI in der oben beschriebenen Weise enthalten, oder?

Ja, Du _kannst_ mit PHP bei vielen Befehlen/Funktionen
nicht nur lokale Dateien auslesen bzw. einbinden, sondern
auch ueber HTTP zugaengliche Ressourcen verwenden.
D.h. Du koenntest notfalls auch eine Ressource, die
sich auf dem eigenen Server befindet, via HTTP
ansprechen und auslesen/einbinden.
(Ob das _sinnvoll_ ist, steht auf einem anderen Blatt...)

Oder was meinst Du mit "aufrufen"?

Wenn Du weitere Fragen hast, werde bitte _noch_ konkreter
bezueglich Dateinamen, Technologien, Befehlen (Quellcode;-).

Freundliche Gruesse,

Thomas

[at]

Hallo.

Sind die "Teile" an sich statische HTML-Bloecke?

Ja, je ein ".inc" für die gemeinsamen Teile

• der Prolog-/Doctype-/Meta-Angaben,
• des Signets (<h1>),
• der Site-Navigation (verschachteltes <ul>/<li>-Konstrukt.

Oder hast Du darin auch noch mal SSI-Befehle?

Nein, [$Goetze] bewahre.

Wenn es sich um statische HTML-Bloecke handelt, kannst Du sie ja
problemlos mit PHP statt mit SSI einbinden.
Dann ist IMHO die Funktion readfile() am besten geeignet.

Dann muss ich ja wieder alle Dateien bearbeiten. Mal sehen, ob mein Editor dafür einen Automatismus bereithält.

http://www.google.com/search?q=random+ssi

Ich hatte nie etwas davon gehört, weswegen ich den vermeintlich einfachen Weg gegangen war.

Vielleicht findest Du ja unter den uebrigen Treffern
einen gute Loesungsansatz...

Der zweite Verweis führt mich zum vielversprechenden Artikel http://www.scriptarchive.com/ssi_image.html :-)

Du musst Dich AFAIK fuer eine Technologie entscheiden...
Vermutlich fuer PHP, da Du ja fuer die Zufallsfunktion
darauf angewiesen bist.

SSI wäre mir aus unterschiedlichen Gründen lieber. Wenn ich die Zufallsfunktion mittels SSI realisieren kann, werde ich wohl dabei bleiben. Falls nicht, muss ich eben konvertieren.

Wenn Du das Skript als ganzes mit PHP realisierst und
nur statische HTML-Bloecke einbindest, dann ist wirklich
nur eine Technologie im Spiel, und die Loesung ist IMHO
"sauber" und "stabil" - auch bei Serverwechsel.

Dann hatte ich das ja bereits richtig vermutet.

Wenn Du aber in den eingebetteten "Teilen" (Includes)
ihrereseits noch SSI-Befehle hast, dann hast Du eben
einen Mix der Technologien - was auf dem einen oder
andern Server zu Problemen fuehren duerfte.

Das gleube ich gern, ist bei mir aber nicht der Fall :-)

Ja, Du _kannst_ mit PHP bei vielen Befehlen/Funktionen
nicht nur lokale Dateien auslesen bzw. einbinden, sondern
auch ueber HTTP zugaengliche Ressourcen verwenden.

So machen es die meisten Kontaktformular-Skripte ja auch.

D.h. Du koenntest notfalls auch eine Ressource, die
sich auf dem eigenen Server befindet, via HTTP
ansprechen und auslesen/einbinden.
(Ob das _sinnvoll_ ist, steht auf einem anderen Blatt...)

Sinnvoll könnte so etwas sein, wenn das Skript an Hand der Formulardaten erkennen soll, welche Seite es zu schicken hat. Die "Auf gut Glück!"-Methode von Google dürfte auf so etwas basieren.

Wenn Du weitere Fragen hast, werde bitte _noch_ konkreter
bezueglich Dateinamen, Technologien, Befehlen (Quellcode;-).

Danke für das Angebot :-)
Ich werde mich aber zunächst ein wenig mit den Suchergebnissen zur SSI-Zufallsfunktion befassen. Damit werde ich dann wohl auch einige Zeit beschäftigt sein, da diese Dinge eigentlich nicht mein Metier sind. Wenn es aber meinen Horizont übersteigt, werde ich sicher gern auf das Angebot zurückkommen.
MfG, at

[Thomas Luethi]

Hallo,

statische HTML-Bloecke [...] mit PHP statt mit SSI einbinden.
Dann muss ich ja wieder alle Dateien bearbeiten. Mal sehen, ob mein Editor dafür einen Automatismus bereithält.

Ich meinte nicht, dass Du alle Seiten aendern muesstest.

Ich ging davon aus, dass Du alle Seiten ausser der Homepage
nicht anfassen willst.

Du muesstest also nur gerade die Homepage "umschreiben" in PHP.

Statt
<!--#include virtual="signet.inc" -->
also einfach
<script language="php"> readfile("signet.inc"); </script>
u.s.w.

btw: Zum dateiuebergreifenden Suchen und Ersetzen
verwendete ich unter Windows meistens Phase 5.
(Vorgaengige Sicherheitskopie empfohlen ;-)
Es gibt auch diverse Spezial-Tools zu diesem Zweck.

Natuerlich kannst Du das jetzt zum Anlass nehmen,
Deine ganze Website von SSI auf PHP umzustellen.
Halte ich aber nicht fuer notwendig, solange
Du wirklich nur mit statischen Includes arbeitest.

Der zweite Verweis führt mich zum vielversprechenden Artikel http://www.scriptarchive.com/ssi_image.html :-)

Soweit ich auf den ersten Blick sehe, wird dort mit SSI
die Ausgabe eines _Perl_-Skripts eingebunden.
(Netterweise gibt Matt nicht mal ein Code-Beispiel dafuer.
Wahrscheinlich waere sowas gemeint:
<!--#include virtual="/cgi-bin/ssi_rand_image.pl" -->
Aber das ist nur meine Mutmassung.)

Das ist natuerlich auch eine Moeglichkeit.
Aber eben auch ein "Mix" von zwei Technologien.
Und somit von der Server-Konfiguration bzw. vom
Provider abhaengig.

Das Script Archive von Matt Wright hat hier im Forum
uebrigens einen sehr schlechten Ruf - die Skripten haben
oft riesige Sicherheitsloecher. Ich wuerde die Finger
davon lassen.

Sinnvoll könnte so etwas sein, wenn das Skript an Hand der Formulardaten erkennen soll, welche Seite es zu schicken hat. Die "Auf gut Glück!"-Methode von Google dürfte auf so etwas basieren.

Google bindet aber die Ressource nicht ein.
Er schickt nur einen HTTP-302-Header.

Das gleiche tut vermutlich die Mehrzahl
der Form-Mailer-Skripten da draussen, wenn
sie Dich auf die "Danke-Seite" weiterschicken.

Natuerlich gibt es auch Ausnahmen, wo z.B.
tatsaechlich das Skript eine HTML-Datei einliest,
darin gewisse Platzhalter ersetzt und danach
den Quelltext selbst an den Browser schickt.

Der Blick in die Adresszeile des Browsers verraet Dir meist,
was der Fall ist...

mfg,
Thomas

[at]

Hallo.

Du muesstest also nur gerade die Homepage "umschreiben" in PHP.

Ja, natürlich. Dass ich gern alle Seiten gleich aufbereiten möchte, ist sicher kein Problem deiner Lösung, sondern eines meines Anspruches ;-)

btw: Zum dateiuebergreifenden Suchen und Ersetzen
verwendete ich unter Windows meistens Phase 5.

Auch mein Editor hält dafür ein Plugin bereit, wie ich soeben festgestellt habe. -- Eigentlich wollte ich SSI ja verwenden, um genau so etwas zu vermeiden ;-)

(Vorgaengige Sicherheitskopie empfohlen ;-)

(Selbstredend ;-)

Natuerlich kannst Du das jetzt zum Anlass nehmen,
Deine ganze Website von SSI auf PHP umzustellen.
Halte ich aber nicht fuer notwendig, solange
Du wirklich nur mit statischen Includes arbeitest.

PHP kann zwar mehr, erfordert aber -- wenngleich für eine Programmiersprache noch relativ wenig -- mehr Lernaufwand, um nicht nur etwas zu tun, sondern auch zu wissen, was man tut und vielleicht sogar, warum ;-)
Ich denke, ich bleibe bei SSI und ändere tatsächlich nur die Titelseite. Diese Lösung ist zwar nicht die eleganteste, aber für mich derzeit sicher die gangbarste.

Soweit ich auf den ersten Blick sehe, wird dort mit SSI
die Ausgabe eines _Perl_-Skripts eingebunden.

Ja, und alle anderen gefundenen "Lösungen" sehen leider ähnlich aus :-(

Das ist natuerlich auch eine Moeglichkeit.
Aber eben auch ein "Mix" von zwei Technologien.
Und somit von der Server-Konfiguration bzw. vom
Provider abhaengig.

Eben.

Das Script Archive von Matt Wright hat hier im Forum
uebrigens einen sehr schlechten Ruf - die Skripten haben
oft riesige Sicherheitsloecher. Ich wuerde die Finger
davon lassen.

Das wusste ich nicht -- wahrscheinlich, weil dies ja eigentlich nicht mein Fachgebiet ist. Ich danke dir für diesen wertvollen Hinweis. Aber welches Archiv könntest du denn empfehlen?

Google bindet aber die Ressource nicht ein.
Er schickt nur einen HTTP-302-Header.

Aha. Das sagt mir zwar nicht viel, aber es war ohnehin nur ein Schuss ins Blaue.

Das gleiche tut vermutlich die Mehrzahl
der Form-Mailer-Skripten da draussen, wenn
sie Dich auf die "Danke-Seite" weiterschicken.

Na ja, das Ergebnis sollte jedenfalls das gleiche sein ;-)
MfG, at

[Thomas Luethi]

Hallo,

Das Script Archive von Matt Wright hat hier im Forum uebrigens einen sehr schlechten Ruf [...]

Das wusste ich nicht -- wahrscheinlich, weil dies ja eigentlich nicht mein Fachgebiet ist. Ich danke dir für diesen wertvollen Hinweis. Aber welches Archiv könntest du denn empfehlen?

Bei Perl kenne ich mich nicht aus.

Und auch in PHP, das ich hauptsaechlich verwende,
habe ich eigentlich alle Skripten selbst geschrieben.
Als Vorlage dienten mir die Beispiele in der dclp-FAQ
sowie im Manual. Dort gehe ich davon aus, dass sie
auf dem neuesten Stand sind, weil sie direkt aus der
Feder der Entwickler stammen  (Manual) bzw. das Werk
einer aktiven Community sind (dclp-FAQ).

Einigermassen trauen wuerde ich noch Skript-Archiven, bei denen
Benutzerkommentare und -Bewertungen moeglich sind.
Wenn ein dort veroeffentlichtest Skript Sicherheitsloecher aufweist,
wird das vermutlich in den Benutzerkommentaren kritisiert.

Google bindet aber die Ressource nicht ein.
Er schickt nur einen HTTP-302-Header.

Aha. Das sagt mir zwar nicht viel, aber es war ohnehin nur ein Schuss ins Blaue.

Auf HTTP-Ebene laeuft das ganze - etwas vereinfacht - so ab:

1. Eine normale Google-Suche:
http://www.google.ch/search?q=telepolis
Der Browser sagt zum Server www.google.ch
GET /search?q=telepolis HTTP/1.1
("Hey, Alter, schick mir mal /search?q=telepolis !")
User-Agent: Mozilla/5.0
("Ich bin Mozilla/5.0")

Google schickt dem Browser zuerst einen HTTP-Head
200 OK ("Alles in Ordnung!")
Content-type: text/html ("Das was jetzt dann gleich kommt, ist HTML-Text")
Dann zwei Leerzeilen.
Dann den eigentlichen Inhalt, also die HTML-Seite
mit der Auflistung der Suchresultate:
<html><head><title>Google Suche: telepolis</title> u.s.w.

In der Adresszeile des Browsers steht "http://www.google.ch/search?q=telepolis"

2. Eine "Auf Gut Glueck!" Suche:

http://www.google.ch/search?q=telepolis&btnI=AufGutGlueck
Der Browser sagt zum Server www.google.ch
GET /search?q=telepolis&btnI=AufGutGlueck HTTP/1.1
("Hey, alter, schick mir mal /search?q=telepolis&btnI=AufGutGlueck !")

Google schickt dem Browser einen anderen HTTP-Head als vorhin:
302 Found (etwa "Ich habe etwas gefunden, aber das ist voruebergehend woanders")
Location: http://www.heise.de/tp/ ("Geh zu dieser URL - da findest Du es")
Content-Type: text/html ("Das was jetzt dann gleich kommt, ist HTML-Text")
Dann zwei Leerzeilen.
Dann ein paar wenige Zeilen HTML-Code, meist etwas im Stil:
<html>
<title>Document moved</title>
<body>
The Document you requested can be found
<a href="http://www.heise.de/tp/">here</a>

Der kurze HTML-Text mit dem Link ist in der HTTP/1.1 Spec.
empfohlen und ist vor allem fuer Browser gedacht, die
keine automatischen Weiterleitungen ausfuehren, sei es,
weil sie zu alt dafuer sind (sehr unwahrscheinlich) bzw.
dass der Benutzer sie so konfiguriert hat (z.B. bei Opera
ohne weiteres moeglich).

Normalerweise holt der Browser aufgrund des 302-Heads
automatisch die neue URL.

Er wendet sich also an www.heise.de
und sagt diesem Server:
GET /tp/ HTTP/1.1 ("Schick mir /tp/ !")

Der heise-Server antwortet dann wie folgt:
200 OK ("Alles in Ordnung!")
Content-type: text/html ("Das was jetzt dann gleich kommt, ist HTML-Text")
Dann zwei Leerzeilen.
Dann den eigentlichen Inhalt, also die HTML-Seite von Telepolis:
<html>
<head><title>TELEPOLIS</title>
u.s.w.

In der Adresszeile des Browsers steht "http://www.heise.de/tp/".

---

Wie die Status Codes offiziell definiert sind, steht in RFC 2616:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
Und natuerlich, auf deutsch und zusammengefasst, auch hier:
http://selfhtml.teamone.de/diverses/httpstatuscodes.htm

Zwei nette Tools, um die HTTP-Header im Browser zu sehen, sind:
http://cgi.w3.org/cgi-bin/headers
http://www.schroepl.net/cgi-bin/http_trace.pl

Das Schroepl-Skript zeigt leider bei 302-Weiterleitungen
direkt das Ergebnis des Umleitungs-Ziels an, also nicht
den 302-Header, sondern direkt den 200-Header der
endgueltigen Seite.

Fuer Google ist der W3-Header-Dienst leider nicht
zu gebrauchen, weil er ehrlicherweise einen "falschen"
UserAgent-String schickt (anstatt vorzuspielen, er sei
ein gewoehnlicher Browser) und Google sich dagegen
mit einer Antwort "403 Forbidden" wehrt, weil Google
nicht will, dass seine Resultate von Maschinen
verwertet werden.

mfg, Thomas

[at]

Hallo.

Bei Perl kenne ich mich nicht aus.

Dann sind wir ja schon zwei ;-)

Und auch in PHP, das ich hauptsaechlich verwende,
habe ich eigentlich alle Skripten selbst geschrieben.

Nun, diesen Ehrgeiz habe ich nicht, da ich nicht wieder für eine Handvoll Skripte in die Grundlagen einsteigen will.

Als Vorlage dienten mir die Beispiele in der dclp-FAQ
sowie im Manual. Dort gehe ich davon aus, dass sie
auf dem neuesten Stand sind, weil sie direkt aus der
Feder der Entwickler stammen  (Manual) bzw. das Werk
einer aktiven Community sind (dclp-FAQ).

Na, das ist doch schon mal etwas.

Einigermassen trauen wuerde ich noch Skript-Archiven, bei denen
Benutzerkommentare und -Bewertungen moeglich sind.
Wenn ein dort veroeffentlichtest Skript Sicherheitsloecher aufweist,
wird das vermutlich in den Benutzerkommentaren kritisiert.

Ja, das klingt nachvollziehbar.

Auf HTTP-Ebene laeuft das ganze - etwas vereinfacht - so ab:

[...]
Danke, das war sehr anschaulich.

Wie die Status Codes offiziell definiert sind, steht in RFC 2616:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
Und natuerlich, auf deutsch und zusammengefasst, auch hier:
http://selfhtml.teamone.de/diverses/httpstatuscodes.htm

Ja, die kenne ich, aber der geschilderte Ablauf wird dort nicht so verständlich dargelegt wie von dir eben.
MfG, at

[Thomas Luethi]

Hallo nochmal,

Ich hab's noch rasch getestet, und zwar auf
zwei verschiedenen Servern.

Beispiel 1:
index.php bindet per PHP-Befehl include() oder virtual()
das erste Include kopfzeile.shtml ein.
Dieses seinerseits bindet per SSI-Befehl ein oder mehrere
weitere Dateien ein, z.B. statische HTML-Dateien logo.html
und navigation.html

Gleiches Ergebnis auf beiden Servern:

include("kopfzeile.shtml")
=> Datei wird unveraendert eingebunden, d.h. SSI-Befehle
   werden _nicht_ ausgefuehrt.

virtual("kopfzeile.shtml")
=> Datei wird geparst eingebunden, d.h. SSI-Befehle
   _werden_ ausgefuehrt, inklusive Einbetten von
   weiteren Dateien.

Beispiel 2:
index.shtml bindet per SSI-Befehl das erste Include
kopfzeile.php ein.
Dieses seinerseits bindet per PHP-Befehl weitere Dateien
ein, z.B. statische HTML-Dateien.

Resultat unabhaengig von der Schreibweise:
<!--#include virtual="kopfzeile.php" -->
oder
<!--#include file="kopfzeile.php" -->

Server bei kommerziellem Webhoster (beide Schreibweisen):
Datei wird geparst eingebunden, d.h. PHP-Befehle werden
ausgefuehrt, inklusive Einbetten von weiteren Dateien.

Uni-Server (bei beiden Schreibweisen): Fehlermeldung:
[an error occurred while processing this directive]

---

Wie gesagt, das "Mixen" der Technologien PHP und SSI,
indem man verschachtelte Includes verwendet, ist
nicht unbedingt zu empfehlen, weil es je nach
Server-Konfiguration nicht funktionieren kann.

Der Weg, als "aeusserste" Datei eine PHP-Datei zu haben,
und damit Seiten einzubinden, die SSI verwenden,
scheint etwas zuverlaessiger zu sein, als der
umgekehrte Weg (SSI-Datei bindet PHP-Dateien ein).

Mit PHP kann man notfalls auch die eigenen Ressourcen
ueber HTTP abholen und einbinden, was mit SSI
nicht moeglich ist.

http://httpd.apache.org/docs-2.0/mod/mod_include.html#includevirtual
  "The URL cannot contain a scheme or hostname,
  only a path and an optional query string."

mfg, Thomas

[at]

Hallo.

Ich hab's noch rasch getestet, und zwar auf
zwei verschiedenen Servern.

Ich danke dir ganz herzlich.
MfG, at

[at]

Hallo.

habe einen Projekt hinter sich.

Diese Formulierung ist zwar sicher falsch, aber ich finde sie schlicht genial, danke. *notier*
MfG, at