nicht angemeldet
Bei Dateien mit ".html"-endung wird PHP nicht geparst
Hallo zusammen!
Ich habe mir gerade SUSE-Linux auf einem Testserver installiert. Apache und co. klappen wunderbar. Wenn ich nur Dateien mit der Endung ".html" habe, und hier PHP-code einbettet, dann wird der nicht geparst. Benenne ich die Datei in ".php" um, dann funktioniert es.
Ich möchte das nur der Vollständigkeit halber ans laufen bringen, weil das sonst eher ungeschickt aussieht.
Kann mir jemand sagen, was ich umkonfigurieren muß !?
Danke und Gruss!
Flo
-
hi!
Ich habe mir gerade SUSE-Linux auf einem Testserver installiert.
Apache und co. klappen wunderbar. Wenn ich nur Dateien mit der
Endung ".html" habe, und hier PHP-code einbettet, dann wird der
nicht geparst. Benenne ich die Datei in ".php" um, dann funktioniert
es.In der Apache-Konfiguration müsste ein Eintrag stehen, der etwa
folgendermaßen aussieht:AddType application/x-httpd-php .php .php4
Da musst du einfach die Endung .html ergängen, dann sollte das schon
funktionieren. Nicht vergessen, im Anschluss den Apache neu zu starten!bye, Frank!
-
hi
Ich habe mir gerade SUSE-Linux auf einem Testserver installiert. Apache und co. klappen wunderbar. Wenn ich nur Dateien mit der Endung ".html" habe, und hier PHP-code einbettet, dann wird der nicht geparst. Benenne ich die Datei in ".php" um, dann funktioniert es.
was volle absicht ist, da der PHP-Interpreter die Performance ca. auf ein 10tel reduziert - also werden eben nur die Dateien, wo es auch wirklich was für PHP zu tun gibt durch das Ding geschickt.
Grüße aus Bleckede
Kai
-
Hallo Kai,
was volle absicht ist, da der PHP-Interpreter die Performance ca. auf ein 10tel reduziert - also
nur der Interesse halber:
_auf_ ein 10tel - oder - _um_ ein 10tel ?
_auf_ ein 10tel wäre ja schon arg fatal und ich müßte mich ernsthaft fragen, wie manche Server bei sehr PHP-lastigen Seiten trotzdem eine ordentliche Performance zustande bringen.
Gruß der_bernd
-
HI Bernd,
nur der Interesse halber:
_auf_ ein 10tel - oder - _um_ ein 10tel ?ganz bestimmt _auf_ ein Zehntel (ich hätte es mir viel noch schlimmer
vorgestellt)._auf_ ein 10tel wäre ja schon arg fatal
Der Faktor, um den es langsamer ist, eine Datei serverseitig zu parsen
als ihren Inhalt (der womöglich sogar schon im RAM gecached ist) einfach
nur auf die Leitung zu kippen, kann auch beliebig viele Zehnerpotenzen
groß sein- je nachdem, wieviel Overhead der HTTP-Request selbst schon
hat. Wenn da noch URL rewriting, .htaccess-Interpretation (mit rekursi-
ver Suche durch den gesamten Dateibaum!) und andere nette Sachen anfal-
len, dann wird das Verhältnis wieder "günstiger".
Kurz gesagt: Je abgespeckter der Server ist, um so höher ist der relative
Overhead von PHP gegenüber der reinen Auslieferung von Datei-Inhalten.und ich müßte mich ernsthaft fragen, wie manche Server bei sehr PHP-
lastigen Seiten trotzdem eine ordentliche Performance zustande bringen.Naja, ein "dicker" Server muß ja in mehreren "Disziplinen" Leistung
bringen - CPU-Power, Festplattengeschwindigkeit, genug RAM für Caching,
schnelle Netzwerkschnittstellen etc.
Bei reinen HTML-Seiten ist die CPU dabei chronisch unterbeschäftigt;
insofern hält ein Massenserver einen _gesunden_ Mix aus diversen Seiten
ganz gut aus. Daß dies bei dem CGI-lastigen Self-Server beispielsweise
durchaus anders aussieht, ist Dir ja auch bewußt.Viele Grüße
Michael-
Hallo Michael,
danke erstmal für die umfassende Antwort, wenn gleich auch einige Sachen für mich (momentan noch) "böhmische Dörfer" sind.
Wenn ich dich richtig verstehe, liegt es also wirklich nur am "guten Mix" der gehosteten Seiten.
Um es mal ganz primitiv auszudrücken:
Wenn ein Hoster mit nem recht dicken Server _nur_ html Seiten drauf hätte - hätte er in die Hardware quasi "überinvestiert".
Unter gleichen Voraussetzungen hätte er u.U. bei _nur_ geparsten Seiten ein ernstes Performance Problem.
Kann man das so ausdrücken?
Gruß der_bernd
-
Hi der_bernd,
Wenn ein Hoster mit nem recht dicken Server _nur_ html Seiten drauf
hätte - hätte er in die Hardware quasi "überinvestiert".er sollte in diesem Falle eher in die Leitung investieren als in die CPU.
Eine schnelle Leitung hilft, schnelle Platten helfen auch, viel RAM ist
immer nützlich.CPU-Power ist eine Ressource, die in der IT-Geschichte immer knapp war,
weshalb es vielfältige Strategien gibt, sie durch andere Ressourcen zu
ersetzen (beispielsweise kann man Ergebnisse vorher berechnen und in
einem Cache ablegen - das ist das Funktionsprinzip von gzip_cnc und
seinem Cache komprimierter Seiten; oder man kann durch zusätzlichen
Speicherplatz vorsortierte Bäume als Zugriffspfade bereitstellen, das
ist das Funktionsprinzip von Datenbank-Indexen).Auch Festplattenzugriffe lassen sich durch die Investition von RAM
(oder durch einen Hardware-Cache auf der Festplatte selbst!) beschleu-
nigen, und ein Flaschenhals bei einem Server kann durch einen vorge-
schalteten caching proxy entschärft werden.Umgekehrt ist es schwieriger, fehlenden RAM durch mehr Power in den
anderen Bereichen zu kompensieren, weil schneller Zwischenspeicher
typischerweise eben gerade von denjenigen Optimierungsmethoden genutzt
wird, die zur Umgehung anderer Engppässe gebaut wurden. Reicht der
dazu erforderliche schnelle Speicher nicht aus, dann kann einen solche
Optimierung sogar in ihr Gegenteil umschlagen (weil der Rechner nun
verzweifelt Seiten ein- und auslagert, statt etwas Sinnvolles zu tun).Unter gleichen Voraussetzungen hätte er u.U. bei _nur_ geparsten
Seiten ein ernstes Performance Problem.Ein Rechner ist eine Lösung einer bestimmten Aufgabenstellung.
Es gibt keinen Rechner, der _alle_ Aufgabenstellungen _optimal_ löst.Je bewußter man sich seiner eigenen Aufgabenstellung ist, desto genauer
kann man diese in Form einzelner Anforderungen fassen - und damit
Mindest-Dimensionen für _alle_ Teile eines Rechnersystems aufstellen,
also erkennen, wo man sparen darf und wo man klotzen sollte, um nicht
den ganzen Rest auszubremsen.Kann man das so ausdrücken?
Zusammenfassend: Ja. ;-)
Viele Grüße
Michael
-
-
-
-
-
hi,
Ich habe mir gerade SUSE-Linux auf einem Testserver installiert. Apache und co. klappen wunderbar.
Nach deiner Problembeschreibung "klappt" da der Apache nicht korrekt - es fehlt ihm was ;-)
Wenn ich nur Dateien mit der Endung ".html" habe, und hier PHP-code einbettet, dann wird der nicht geparst. Benenne ich die Datei in ".php" um, dann funktioniert es.
_Genau das_ ist ein Hinweis, daß du versäumt hast, dem Apache in der httpd.conf mitzuteilen, daß er auch solche Dateien korrekt weitergeben soll. Schau dir deine httpd.conf insbesondere auf die Einträge "AddType application/x-httpd-php" und "AddHandler server-parsed" noch mal durch, da sollten auch HTML-Dateien drinstehen, wenn sie mit PHP-Inhalt "geparst" werden sollen
Grüße aus Berlin
Chrsitoph S.
-
Hallo
[..]
_deine httpd.conf insbesondere auf die Einträge "AddType application/x-httpd-php" und "AddHandler server-parsed" noch mal durch, da sollten auch HTML-Dateien drinstehen, wenn sie mit PHP-Inhalt "geparst" werden sollen
...was wohl nicht immer so besonders sinnvoll ist, wie bereits hier erwähnt wurde..
Gruss Sven
-
hi Sven,
...was wohl nicht immer so besonders sinnvoll ist, wie bereits hier erwähnt wurde..
was für ihn selbst "wichtig" oder "sinnvoll" ist, muß jeder selbst entscheiden. Ich persönlich halte es nicht für besonders glücklich, aber wenn jemand unbedingt möchte, dann muß die Möglichkeiten gezeigt bekommen, die es aus gutem Grund auch gibt.
Christoph S.
-
-
-
Ich habe mir gerade SUSE-Linux auf einem Testserver installiert. Apache und co. klappen wunderbar. Wenn ich nur Dateien mit der Endung ".html" habe, und hier PHP-code einbettet, dann wird der nicht geparst. Benenne ich die Datei in ".php" um, dann funktioniert es.
Ich möchte das nur der Vollständigkeit halber ans laufen bringen, weil das sonst eher ungeschickt aussieht.
Huch, was sieht ungeschickt aus? Du meinst doch nicht etwa, daß eine URL, die auf .php endet professioneller aussieht, als eine, die auf .html endet?
Sind wir schon so weit, ist es schon so schlimm? Zählt gutes Seitendesign garnichts mehr? Geht es nur noch darum, was hinten dran hängt?
Und was soll ich machen, URLs in meinem Kino-Fahrplan haben doch garkeine Endung mehr, egal ob HTML, SSI, PHP oder CGI drinsteckt. Sind solche schwanzlosen Subjekte jetzt vollends der Lächerlichkeit preisgegeben oder gilt das doch als geheimer Geheimtipp allerhöchster Professionalität?Und in welchen Self-Themenbereich fällt sowas?
Fragen über Fragen.. ;)
Gruß,
soenk.e-
Hallo,
Und was soll ich machen, URLs in meinem Kino-Fahrplan haben doch garkeine Endung mehr, egal ob HTML, SSI, PHP oder CGI drinsteckt. Sind solche schwanzlosen Subjekte jetzt vollends der Lächerlichkeit preisgegeben oder gilt das doch als geheimer Geheimtipp allerhöchster Professionalität?
natürlich eher das zweite. Für den normalen Besucher, dem es egal ist bzw. sein sollte, wie die Seite entsteht, ist es meiner Meinung eher ein Mehrwert, eine sprechende URL à la
http://kino-fahrplan.de/programm/grindel alz z.B. http://.../view.php?id=559&action=7X89 in der Adresszeile vorzufinden. Die Dateiendung kann ja bei entsprechender Konfiguration (MultiViews) wegfallen, also warum nicht?
Einen kleinen Wermutstropfen gibt es allerdings: Wenn jemand bei der (Deep-)Verlinkung ganz besonders korrekt sein will und noch einen Slash an den Dateinamen ("Dateiname? Nö, ist doch ein Verzeichnis, hat ja keine Endung!") anfügt, gibt's einen 404, was dann eventuell wieder unprofessionell aussieht.
Aber damit kann man, denke ich, leben.Das wäre übrigens auch eine Lösung für die ursprüngliche Frage:
MultiViews an, die Dateien alle in Dateiname.html.php umbenennnen und gegenseitig als Dateiname.html bzw. Dateiname.html?parameter=wert verlinken. Der Nutzen dessen will sich mir aber auch nicht erschließen...Und in welchen Self-Themenbereich fällt sowas?
Natürlich SERVER, weil die Möglichkeit dazu ja erst in httpd.conf oder .htaccess gechaffen wurde ;-)
Schönen Gruß aus Bilk
Rainer
-