nicht angemeldet Ingo Siemon
Ingo Siemon
Dennis
Ingo Siemon
Swen Wacker
Ingo Siemon
Ingo Siemon
Ingo Siemon
Dennis
Hallo
Ich habe auf meiner Startseite ein kleines PHP-Script laufen,
welches dafür sorgt, dass dort per Zufall 4 verschiedene Bilder
angezeigt werden:
<?php
$zahl = range(1, 25);
shuffle($zahl);
echo "<img src=\"bilder/neu/SPACEart-".$zahl[0].".jpg\" alt=\"\" />";
echo "<img src=\"bilder/neu/SPACEart-".$zahl[1].".jpg\" alt=\"\" />";
echo "<img src=\"bilder/neu/SPACEart-".$zahl[2].".jpg\" alt=\"\" />";
echo "<img src=\"bilder/neu/SPACEart-".$zahl[3].".jpg\" alt=\"\" />";
?>
Das funtioniert auch sehr gut.
Nun ist es aber so, dass der Aufruf der Startseite in den
Abendstunden doch deutlich länger dauert.
Ich habe die Vermutung, dass der PHP-Parser meines Hosting-Providers
da wohl viel zu tun hat und es dann eben etwas länger dauert,
bis die Startseite durch den PHP-Parser durch ist.
Ich habe das mal gegengescheckt ohne PHP und da gehts dann blitzschnell.
Nun dachte ich, man könnte diese Bilder-Zufalls-Anzeige
doch auch mit SSI machen. Ist das denn schneller?
Kann man dazu irgendwelche generellen Aussagen machen?
Mich würden Eure Meinungen und Erfahrungen diesbezüglich
sehr interessieren.
Gruß
Ingo
hi,
Nun dachte ich, man könnte diese Bilder-Zufalls-Anzeige
doch auch mit SSI machen. Ist das denn schneller?
Generell ist das Script ein kleiner Furz für den PHP-Prozessor, eine Verzögerung beim Seitenaufbau gegenüber einer statischen Seitenversion sollte sich das gar nicht feststellen lassen.
Wenn du aber sagst,
Ich habe die Vermutung, dass der PHP-Parser meines Hosting-Providers da wohl viel zu tun hat und es dann eben etwas länger dauert, bis die Startseite durch den PHP-Parser durch ist.
Kann man dazu irgendwelche generellen Aussagen machen?
Nein, eher nicht.
Ob du solche Kleinigekeiten per PHP oder per SSI (wobei ich da im Moment nicht genau wüsste, wie in diesem Falle) machen lässt, dürfte vom Rechenaufwand her ziemlich unerheblich sein.
Ja, es wäre möglich, dass der SSI-Parser weniger ausgelastet ist, und du damit schneller "bedient" wirst. Wenn aber der ganze Webserver generell unter zu hoher Last leidet, wird das vermutlich auch wenig bringen.
gruß,
wahsaga
Lieber wahsaga
Wenn aber der ganze Webserver generell unter zu hoher Last leidet, wird das vermutlich auch wenig bringen.
Naja, ich habe das halt einfach zur selben Zeit (in den Abendstunden)
mal ohne PHP getestet. Also so, dass die Bilder einfach ganz normal
per html-Eingebunden waren.
Und da gings dann blitzschnell (mal abgesehen, vom Aufbau der Bilder selbst).
Kann ich daraus denn nicht schliessen, dass der Webserver selbst
schon flott genug ist. Der ist doch auch für die Auslieferung
der .htm-Dateien zuständig.
Nur wenn ich meine index.htm eben per
<Files ~ (index|fehler|ausverkauft)\.htm>
AddType x-mapp-php4 .php .htm
</Files>
durch den PHP-Paser schicke, dauerts so lange.
Gruß
Ingo
hallo,
Naja, ich habe das halt einfach zur selben Zeit (in den Abendstunden)
mal ohne PHP getestet.
Und warum hast du nicht auch gleich einen Test mit SSI hinterhergeschoben? Ich würde so testen:
<!--#include virtual="bilder.inc" -->
Wobei in "bilder.inc" stehen müßte:
<a href="/bilddatei.png">
und gegebenenfalls ein "Zufallsgenerator" für zufällig ausgewählte Bilder, der dann allerdings nicht mit PHP arbeiten könnte (das soll ja gegengeprüft werden), sondern entweder mit einer anderen serverseitigen Technik (Perl, Python, ruby ...) oder aber mit Javascript.
mal abgesehen, vom Aufbau der Bilder selbst
ok, aber das ist eine andere Geschichte.
Kann ich daraus denn nicht schliessen, dass der Webserver selbst
schon flott genug ist.
Vermutlich kannst du das, ja.
Nur wenn ich meine index.htm eben per
<Files ~ (index|fehler|ausverkauft).htm>
AddType x-mapp-php4 .php .htm
</Files>
> durch den PHP-Paser schicke, dauerts so lange.
Ähm ... das hat mit HTML nichts zu tun, und mit PHP auch nichts. Das hat was mit .htaccess zu tun. Und da gibts zwei Dinge:
1\. Wie kommst du auf den Mime-Typ x-mapp-php4? Für PHP wäre
AddType application/x-httpd-php .php
zuständig.
2\. Warum läßt du \_alle\_ htm-Dateien durch den Parser jagen? Das ist eine deutliche Erhöhung deiner eigenen, also von dir erzeugten, Serverlast, das solltest du vermeiden.
Grüße aus Berlin
Christoph S.
--
[Visitenkarte](http://community.de.selfhtml.org/visitenkarten/view.php?key=26)
<http://www.christoph-schnauss.de>
ss:| zu:) ls:& fo:) va:) sh:| rl:|
Hi Christoph,
- Wie kommst du auf den Mime-Typ x-mapp-php4? Für PHP wäre
AddType application/x-httpd-php .php
zuständig.
Wenn PHP über CGI oder über FastCGI läuft die die Definition des MimeTypes reine Entscheidung des Hostes. Ich kenne ein paar Hoster, die da auf so krumme Ideen kommen...
- Warum läßt du _alle_ htm-Dateien durch den Parser jagen? Das ist eine deutliche Erhöhung deiner eigenen, also von dir erzeugten, Serverlast, das solltest du vermeiden.
Wieso? <Files ~ (index|fehler|ausverkauft)\.htm> beschränkt das doch auf drei .htm Dateien - oder sehe ich das falsch? Unabhängig davon, kann das IHMO nur schlecht direkt mit dem Problem zusammen hängen, da dieses ja nur zeitlich begrenzt auftritt.
MfG, Dennis.
hallo Dennis,
Wenn PHP über CGI oder über FastCGI läuft
Das ist bei einem seriösen Webhoster unwahrscheinlich
die die Definition des MimeTypes reine Entscheidung des Hostes.
Jaein. Wenn der Serveradmin da Unsinn einstellt, läßt es sich ja korrigieren in der .htaccess, aber nicht dadurch, daß man nochmal Unsinn dagegensetzt.
Ich kenne ein paar Hoster, die da auf so krumme Ideen kommen...
;-)
- Warum läßt du _alle_ htm-Dateien durch den Parser jagen? Das ist eine deutliche Erhöhung deiner eigenen, also von dir erzeugten, Serverlast, das solltest du vermeiden.
Wieso?<Files ~ (index|fehler|ausverkauft)\.htm>beschränkt das doch auf drei .htm Dateien
Das _soll_ es mögliherweise. Ist aber in meinen Augen ebenso Unsinn. Wenn man keine Platzhalter (*) verwenden will, aber trotzdem mehrere Dateinamen angegeben werden sollen, geht das durchaus - aber nicht mit <Files>, sondern dann mit <FilesMatch> und einem Regulären Ausdruck. Als Beispiel:
<FilesMatch ".(htm|php)$">
scheucht alle *.htm und *.php durch den Parser.
kann das IHMO nur schlecht direkt mit dem Problem zusammen hängen
Oh doch. Es wird eingach eine .htaccess eingesetzt, die vorn und hinten nicht stimmt und dem Server erhebliche Probleme bereitet.
da dieses ja nur zeitlich begrenzt auftritt.
Die "zeitliche Begrenzung" ist nur zufällig der Aufhänger. Das Grundproblem liegt aller Wahrscheinlichkeit sowohl in der allgemeienen Belastung des Servers in den Abendstunden wie auch in dieser ziemlich abstrusen und für mich nicht nachvollziehbaren Konstruktion, wie hier PHP "initialisiert" wird.
Grüße aus Berlin
Christoph S.
Hi Christoph,
Wenn PHP über CGI oder über FastCGI läuft
Das ist bei einem seriösen Webhoster unwahrscheinlich
CGI fällt aus Performance-Gründen flach, das stimmt - aber FastCGI bietet einen guten Ersatz, was hast du dagegen? Ich halte PHP über FastCGI in Verbindung mit suExec für eine der besten und saubersten Lösungen was eine Multi-User Umgebung mit diversen Scriptsprachen angeht.
Außerdem lassen sich nur über (Fast)CGI mehrere PHP Versionen gleichzeitig betreiben, sowie z.B. 1und1 PHP4 und PHP5 gleichzeitig anbietet (.php und .php5 Dateien).
die die Definition des MimeTypes reine Entscheidung des Hostes.
Jaein. Wenn der Serveradmin da Unsinn einstellt, läßt es sich ja korrigieren in der .htaccess, aber nicht dadurch, daß man nochmal Unsinn dagegensetzt.
Warum willst du bzw. will man allgemin immer so an application/x-httpd-php festhalten? Ich halte das eh für zu fest "hinterlegt" - das sieht man z.B. daran, das sich bei der Modul Version von PHP der Mime Type nicht anpassen lässt.
[ ... <Files ~ ..> ... ]
Das _soll_ es mögliherweise. Ist aber in meinen Augen ebenso Unsinn. Wenn man keine Platzhalter (*) verwenden will, aber trotzdem mehrere Dateinamen angegeben werden sollen, geht das durchaus - aber nicht mit <Files>, sondern dann mit <FilesMatch> und einem Regulären Ausdruck. Als Beispiel:
<FilesMatch ".(htm|php)$">
scheucht alle *.htm und *.php durch den Parser.
Gut, FilesMatch wäre die korrekte[tm] Alternative dazu - Files mit ~ bewirkt aber selbiges.
da dieses ja nur zeitlich begrenzt auftritt.
Die "zeitliche Begrenzung" ist nur zufällig der Aufhänger. Das Grundproblem liegt aller Wahrscheinlichkeit sowohl in der allgemeienen Belastung des Servers in den Abendstunden wie auch in dieser ziemlich abstrusen und für mich nicht nachvollziehbaren Konstruktion, wie hier PHP "initialisiert" wird.
Ja, das ist mir nach dem Klick auf "Absenden" auch eingefallen ;-)
MfG, Dennis.
hallo Dennis,
Wenn PHP über CGI oder über FastCGI läuft
Das ist bei einem seriösen Webhoster unwahrscheinlich
CGI fällt aus Performance-Gründen flach, das stimmt
Gut, dann sind wir an dieser Stelle derselben Ansicht.
aber FastCGI bietet einen guten Ersatz, was hast du dagegen?
Ich habe gar nichts dagegen, mir ist nur nicht bekannt, daß das eben von seriösen Hostern so gehandhabt wird.
Ich halte PHP über FastCGI in Verbindung mit suExec für eine der besten und saubersten Lösungen was eine Multi-User Umgebung mit diversen Scriptsprachen angeht.
Bittesehr. Meine bisherigen Erfahrungen erlauben mir eine solche Aussage nicht. Was auch daran liegt, daß ich "FastCGI in Verbindung mit suExec" nur einmal ganz flüchtig angekuckt, aber bisher nicht wirklich ausprobiert/getestet habe.
Außerdem lassen sich nur über (Fast)CGI mehrere PHP Versionen gleichzeitig betreiben, sowie z.B. 1und1 PHP4 und PHP5 gleichzeitig anbietet (.php und .php5 Dateien).
Das nun wieder halte ich für einen Irrtum, und wenn ich mich recht erinnere, müßte das Forumsarchiv auch ein paar Texte von Christoph Zurnieden zu dieser Frage der Parallelinstallation unterschiedlicher PHP-Versionen hergeben - bin jetz bloß zu faul zum Suchen. Ein "großer" Hoster wie 1und1 wird ja wohl keine Probleme haben, für seine unterschiedlichen Webhosting-Angebote auch unterschiedliche PHP-Versionen (sofern überhaupt gestattet) einzurichten. Wir wissen bloß nicht, ob der OP seinen Internetauftritt bei 1und1 hosten läßt.
Warum willst du bzw. will man allgemin immer so an application/x-httpd-php festhalten?
Ich "will" das gar nicht. Ich finde nur in allen Dokumentationen sowohl für den Apache wie auch für PHP immer nur _diese_ Angabe.
Ich halte das eh für zu fest "hinterlegt" - das sieht man z.B. daran, das sich bei der Modul Version von PHP der Mime Type nicht anpassen lässt.
Ups? Wie meinst du das? Selbst bei einer "Modulvariante" unter einem auf WindowsXP laufenden Apache kann ich problemlos MIME-Typen "anpassen" bzw. über eine .htacces erlauben/verbieten. Und nach allem, was mir bisher bekannt ist, ist der MIME-Typ für PHP nun einmal festgelegt, was ja auch sehr viel Gutes hat.
Als Beispiel:
<FilesMatch ".(htm|php)$">
scheucht alle *.htm und *.php durch den Parser.
Gut, FilesMatch wäre die korrekte[tm] Alternative dazu - Files mit ~ bewirkt aber selbiges.
Nö. Es sei denn, der angesprochene Apache hat schon ein paar Jahresringe angesetzt und versteht <FilesMatch> gleich gar nicht.
Grüße aus Berlin
Christoph S.
Moin!
Als Beispiel:
<FilesMatch ".(htm|php)$">
scheucht alle *.htm und *.php durch den Parser.
Gut, FilesMatch wäre die korrekte[tm] Alternative dazu - Files mit ~ bewirkt aber selbiges.Nö. Es sei denn, der angesprochene Apache hat schon ein paar Jahresringe angesetzt und versteht <FilesMatch> gleich gar nicht.
<Files> versteht der Apache seirt Version 1.2 - <FilesMatch> seit Version 1.3.
Die Doku von 1.3 schreibt, <FilesMatch regex> wäre gegenüber <Files ~ regex> vorzuziehen, begründet dies aber leider nicht. Die Doku für 2.0 schreibt das nicht mehr.
Fakt ist auch, dass beide Versionen funktionsgleich sind.
Was also hast du genau daran herumzumäkeln?
- Sven Rautenberg
Hi Christoph,
Sorry, dass ich erst jetzt wieder dazu komme, hier zu schreiben - aber ich war in den letzten Tagen ziemlich beschäftigt, sodass dieser Thread etwas in Vergessenheit geraten ist ;-)
aber FastCGI bietet einen guten Ersatz, was hast du dagegen?
Ich habe gar nichts dagegen, mir ist nur nicht bekannt, daß das eben von seriösen Hostern so gehandhabt wird.
Nun - soweit ich weiß, ist diese Alternative ja auch nicht so gerade das Älteste, was es gibt. Abgesehen davon: Occuris verwendet diese Methode ;-) Und ich bin eh immer der Meinung, dass nicht immer das was alle machen das beste ist.
Ich halte PHP über FastCGI in Verbindung mit suExec für eine der besten und saubersten Lösungen was eine Multi-User Umgebung mit diversen Scriptsprachen angeht.
Bittesehr. Meine bisherigen Erfahrungen erlauben mir eine solche Aussage nicht. Was auch daran liegt, daß ich "FastCGI in Verbindung mit suExec" nur einmal ganz flüchtig angekuckt, aber bisher nicht wirklich ausprobiert/getestet habe.
Auch wenn deine Erfahrungen aufgrund längeren daseins in den Sachen sicherlich größer sind, als die meiningen, so halte ich es doch für sinnvoll, suExec o.ä. einzusetzen - hierbei wirst du mir vermutlich auch noch zustimmen.
Doch wenn du PHP als ein Apache Modul verwendest, kannst du es (AFAIK) nur mit suPHP und nicht mit suExec kontrollieren - d.h. für den Administrator, dass er ein Modul mehr pflegen muss. Jedoch lassen sich die Aufgaben von suPHP auch prima mit suExec realisieren, wie z.B. dieses Howto (für Debian) zeigt.
Außerdem lassen sich nur über (Fast)CGI mehrere PHP Versionen gleichzeitig betreiben, sowie z.B. 1und1 PHP4 und PHP5 gleichzeitig anbietet (.php und .php5 Dateien).
Das nun wieder halte ich für einen Irrtum, und wenn ich mich recht erinnere, müßte das Forumsarchiv auch ein paar Texte von Christoph Zurnieden zu dieser Frage der Parallelinstallation unterschiedlicher PHP-Versionen hergeben.
Ja, aber immer läuft es darauf hinaus, dass bei zwei parallel installieren PHP Versionen mindestens eine davon über CGI eingebunden wird - ich erinnere mich da z.B. an diesen Thread wo dedlfix sogar versucht hat, den PHP Quellcode entsprechend zu modifizieren, was aber auch misslungen ist.
Ich habe jetzt im Archiv auch nichts entsprechendes gefunden - eine Suche nach "Christoph Zurnieden php zwei versionen" gab keine erfolgreichen Treffer.
Ein "großer" Hoster wie 1und1 wird ja wohl keine Probleme haben, für seine unterschiedlichen Webhosting-Angebote auch unterschiedliche PHP-Versionen (sofern überhaupt gestattet) einzurichten. Wir wissen bloß nicht, ob der OP seinen Internetauftritt bei 1und1 hosten läßt.
Nicht für unterschiedliche Webangebote! Da ich auch bei 1und1 bin, habe ich es gerade noch mal getestet - *.php Dateien werden mit PHP 4.4.1 geparst, *.php5 Dateien mit PHP 5.0.5.
Äußerst interessant ist, dass bei beiden Versionen in der phpinfo() steht:
ServerAPI CGI
Da scheint also tatsächlich PHP über CGI zu laufen ...
Ich halte das eh für zu fest "hinterlegt" - das sieht man z.B. daran, das sich bei der Modul Version von PHP der Mime Type nicht anpassen lässt.
Ups? Wie meinst du das? Selbst bei einer "Modulvariante" unter einem auf WindowsXP laufenden Apache kann ich problemlos MIME-Typen "anpassen" bzw. über eine .htacces erlauben/verbieten.
Wo kannst du denn das was anpassen? Bei mir unter WinXP sieht die Einbindung von PHP4 als Apache Modul so aus:
LoadFile "C:/Server/xampp/php/php4/php4ts.dll"
LoadModule php4_module "C:/Server/xampp/php/php4/php4apache2.dll"
AddType application/x-httpd-php .php .php3 .php4
Wo kann ich hier denn das application/x-httpd-php ändern? Und das ist ja gerade, was ich meine - das application/x-httpd-php scheint vom Modul vorgegeben zu werden und ich habe keinen Einfluss darauf.
Gut, FilesMatch wäre die korrekte[tm] Alternative dazu - Files mit ~ bewirkt aber selbiges.
Nö. Es sei denn, der angesprochene Apache hat schon ein paar Jahresringe angesetzt und versteht <FilesMatch> gleich gar nicht.
Hierzu hat sich Sven ja schon geäußert.
MfG, Dennis.
Lieber Christoph S.
Und warum hast du nicht auch gleich einen Test mit SSI hinterhergeschoben?
Naja, weil ich bisher noch nicht viel von SSI verstehe.
Ich meine, ich weiss nicht wie und vor allem ob sich so eine
Zufalls-Bilderanzeige mit SSI lösen lässt.
Bevor ich mich da ran mache, wollte ich eben erstmal wissen,
obs überhaupt daran liegen könnte ... Du verstehst?
- Wie kommst du auf den Mime-Typ x-mapp-php4? Für PHP wäre
AddType application/x-httpd-php .php
zuständig.
Ups, ich muss gestehen, das habe ich mir ergoogelt,
ohne es so 100%tig zu verstehen.
- Warum läßt du _alle_ htm-Dateien durch den Parser jagen?
Hö, ich dachte das mache ich garnicht.
Mit
<Files ~ (index|fehler|ausverkauft)\.htm>
AddType x-mapp-php4 .php .htm
</Files>
schicke ich doch nur index.htm, fehler.htm und ausverkauft.htm
durch den PHP-Parser.
Oder etwas nicht?
Gruß
Ingo
hallo Ingo,
ich weiss nicht wie und vor allem ob sich so eine
Zufalls-Bilderanzeige mit SSI lösen lässt.
Nicht mit SSI alleine, weil der "Zufallsgenerator" ja noch irgendwie gebaut werden muß. Für eine statische Bilderanzeige wäre SSI durchaus einsetzbar, in der Regel aber nicht nötig.
Bevor ich mich da ran mache, wollte ich eben erstmal wissen,
obs überhaupt daran liegen könnte ... Du verstehst?
Das verstehe ich schon, und da gibts auch noch ein paar Aussagen in einer ziemlich bekannten Dokumentation ...
- Wie kommst du auf den Mime-Typ x-mapp-php4? Für PHP wäre
AddType application/x-httpd-php .php
zuständig.
Ups, ich muss gestehen, das habe ich mir ergoogelt,
ohne es so 100%tig zu verstehen.
Du hättest auch hier nachschauen können.
- Warum läßt du _alle_ htm-Dateien durch den Parser jagen?
Hö, ich dachte das mache ich garnicht.
Mit
<Files ~ (index|fehler|ausverkauft).htm>
AddType x-mapp-php4 .php .htm
</Files>
> schicke ich doch nur index.htm, fehler.htm und ausverkauft.htm
> durch den PHP-Parser.
Nein. Die Gesamtkonstruktion ist falsch. Eigentlich müßte der Server dir permanent melden, daß er nicht versteht, was du von ihm willst.
Außerdem: was hat denn deine index.htm mit PHP zu tun? Wenn es eine PHP-Seite ist, sollte sie index.php heißen, und du kannst dir dann sämtlichen Krimskrams mit <Files> sparen. Entweder darfst du PHP ausführen (lassen), oder du darfst es nicht. Deine Einstellungen sind meines Erachtens wirkungslos.
Grüße aus Berlin
Christoph S.
--
[Visitenkarte](http://community.de.selfhtml.org/visitenkarten/view.php?key=26)
<http://www.christoph-schnauss.de>
ss:| zu:) ls:& fo:) va:) sh:| rl:|
Moin!
<Files ~ (index|fehler|ausverkauft).htm>
AddType x-mapp-php4 .php .htm
</Files>
Hehe, wir haben hier auch Codeblöcke für Apache-Configs. :)
> > schicke ich doch nur index.htm, fehler.htm und ausverkauft.htm
> > durch den PHP-Parser.
>
> Nein. Die Gesamtkonstruktion ist falsch. Eigentlich müßte der Server dir permanent melden, daß er nicht versteht, was du von ihm willst.
Christoph, kannst du diese Aussage mal näher begründen? Denn offenbar meldet der Webserver ja nichts dergleichen.
Zugegeben, speziell für eine Gruppe von Dateien, die auf ".htm" enden, zu definieren, dass Dateien, die auf ".php" enden, vom PHP-Parser zu behandeln sind, ist ziemlich unsinnig, aber ".htm" steht ja auch noch da.
> Außerdem: was hat denn deine index.htm mit PHP zu tun? Wenn es eine PHP-Seite ist, sollte sie index.php heißen, und du kannst dir dann sämtlichen Krimskrams mit <Files> sparen. Entweder darfst du PHP ausführen (lassen), oder du darfst es nicht. Deine Einstellungen sind meines Erachtens wirkungslos.
Endungen in URLs haben sowieso nichts mit der ihnen zugrundeliegenden Techniken zur Generierung zu tun. Eine Startseite "index.htm" zu nennen, ist durchaus legitim, diese Benennung beizubehalten, wenn man von statischem HTML auf PHP umsteigt, ist ebenfalls legitim, weil mutmaßlich diverse externe Links gesetzt sind, die man nicht ändern kann, und die auch nicht umgeleitet werden sollten. "Cool URIs don't change." Die Bezeichnung der generierenden Technik in der Dateiendung ist ein Hilfsmittel für den Webserver - ebenso kann man in Dateiendungen den zu benutzenden Mime-Typ, die Zeichensatzcodierung und eventuelle Komprimierungen codieren, die der Apache-Server dann alle dynamisch während des Requests in HTTP-Header umsetzt.
- Sven Rautenberg
--
My sssignature, my preciousssss!
Moin,
- Wie kommst du auf den Mime-Typ x-mapp-php4?
U.a. 1und1 empfiehlt das seinen Kunden.
Viele Grüße
Swen Wacker
Lieber Swen
- Wie kommst du auf den Mime-Typ x-mapp-php4?
U.a. 1und1 empfiehlt das seinen Kunden.
Yep, stimmt, nun erinnere ich mich auch wieder,
dass ich das daher hatte.
Ich habe meine Seite zwar nicht bei 1+1 gehostet,
aber bei Schlund+Partner, was ja im Grunde das gleiche ist.
Ist denn dann nun die Angabe:
<Files ~ (index|fehler|ausverkauft)\.htm>
AddType x-mapp-php4 .php .htm
</Files>
in meiner .htaccess-Datei doch richtig, wenn ich nur erreichen möchte,
dass von meinen .htm-Dateien nur die index.htm, fehler.htm und ausverkauft.htm durch den PHP-Parser geschickt werden?
Da ich von diesen Dingen nicht so superviel verstehe,
würde ich mich da über Hilfestellung sehr freuen.
Gruß
Ingo
hallo Ingo,
- Wie kommst du auf den Mime-Typ x-mapp-php4?
U.a. 1und1 empfiehlt das seinen Kunden.
Yep, stimmt, nun erinnere ich mich auch wieder,
dass ich das daher hatte.
Ok, ich habe keinen Account bei 1und1 und kenne deren Konfigurationen nicht. Wenn dein Provider dir so etwas schreibt, dann ist das so gewollt, und dann wirds wohl auch funktionieren. Prinzipiell wäre es sogar möglich, daß er dir
AddType honigbroetchen .php .htm
vorschlägt, die Einstellungen dafür kann der Provider an anderer Stelle vornehmen. 1und1 wird das vermutlich so gemacht haben, damit getrennt PHP4 und PHP5 angeboten werden können, das ist deren Sache.
Grüße aus Berlin
Christoph S.
Lieber Christoph
Wenn dein Provider dir so etwas schreibt, dann ist das so gewollt, und dann wirds wohl auch funktionieren.
Yep, inzwischen habe ich sogar bei meinem Provider ein paar
Infos dazu gefunden.
Ich habe weiteres dazu ganz oben in diesem Thraed nochmal gepostet:
https://forum.selfhtml.org/?t=118468&m=759711
Danke auch nochmal für Deine nette Hilfe und
Gruß aus Münster
Ingo
Hallo nochmal
Vielen Dank für Eure zahlreichen Beiträge.
Ich muss aber leider gestehen, dass das meine Kompetenzen nun
doch übersteigt.
Ich habe auf meiner Seite eigentlich insgesamt so gut wie kein PHP
im Einsatz. Nur eben auf der Startseite so ein kleines Stückchen PHP
für dies Zufalls-Bildanzeige.
Darum wollte ich mit folgendem Code in der .htaccess-Datei
eben die 3 Dateien index.htm, fehler.htm und ausverkauft.htm
durch den PHP-Parser "schicken".
Wie schon gesagt hatte ich mir den Code dazu sozusagen "erGoogelt":
<Files ~ (index|fehler|ausverkauft)\.htm>
AddType x-mapp-php4 .php .htm
</Files>
Nun schreibt Ihr mir hier ja, dass das nicht richtig ist und
eigentlich auch garnicht funtionieren durfte.
Tut es aber schon, seht selbst: http://spaceart.de/_Test/
Könntet Ihr mir denn vielleicht behilflich sein und sagen,
wie ich das gewünschte mit der .htaccess-Datei ganz korrekt erreiche?
Darüber würde ich mich wirklich riesig freuen.
Gruß aus Münster
Ingo Siemon
Hallo nochmal
Ich habe da gerade doch noch was in der Hilfe meines
Hosting-Providers gefunden:
https://service.schlund.de/service/dynframeset.php4?http://faq.kundenserver.de/sofort_hilfe_faq/technische_fragen/web_hosting/scripte_cgi_php_asp_etc_/_htaccess/2.html
Da steht nun ganz genau:
"Folgende Direktive ermöglicht es, dass z.B. Dateien mit der Endung html wie PHP-Dateien behandelt werden. Fügen Sie folgende Zeile in die .htaccess ein:"
"AddHandler x-mapp-php4 .html"
Dann muss es doch nun folgendermassen aussehen,
wenn ich nur die index.htm, fehler.htm und ausverkauft.htm
durch den PHP-Parser "schgicken" möchte:
<Files ~ (index|fehler|ausverkauft)\.htm>
AddHandler x-mapp-php4 .htm
</Files>
Richtig?
Gruß
Ingo
Hi Ingo,
Richtig?
Richtig.
MfG, Dennis.
Lieber Dennis
Richtig.
Danke.
Gruß
Ingo