Öffnen von PHP-Dateien auf dem Client
Tom
- sonstiges
0 Maxx0 Tom
0 Sven Rautenberg
Hello,
schon wieder ich.
Irgendwie habe ich gerade einen Denkknoten. Wer kann mirt das mal erläutern?
Szenario:
Windows 98
IE 5.5
Textpad
Kein lokales PHP
Kein lokaler Webserver
PHP-Dateien sind auf dem System mit Textpad assoziiert.
Im Verzeichnis der HTML-Datei des Artikels, den ich schreibe, liegt auch eine *.php-Datei. Über den Link "Anzeigebeispiel: So sieht's aus" ist sie verlinkt. Natürlich kann sie nicht ausgeführt werden. Sie enthält auch in Wirklichkeit nur das Ergebnis des Codes, dass die dazugehörige "echte" PHP-Datei erzeugen würde.
Nun bekomme ich aber auf dem Client das Downloadfesnter angezeigt. Wieso?
Das steht drin: Das Dateihandle lautet: Resource id #2
Ich wäre jetzt nicht irritiert, wenn eine andere Fake-Datei (auch eine *.php) nicht wie erwartet angezeigt werden würde. Die beginnt allerdings auch mit einem gültigen Tag. (<br>)
Liegt es jetzt an der Assoziation oder daran, dass der Browser keinen Doctype erkennen will / erkennen kann?
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Hallo Tom,
Im Verzeichnis der HTML-Datei des Artikels, den ich schreibe, liegt auch eine *.php-Datei. Über den Link "Anzeigebeispiel: So sieht's aus" ist sie verlinkt.
Nun bekomme ich aber auf dem Client das Downloadfesnter angezeigt. Wieso?
Ich habe hier leider kein Win98 zum ausprobieren. Gab es da nicht irgendwie die Möglichkeit den Mimetype zu beeinflussen? Oder du versuchst es mit:
<a href="diedatei.php" type="text/html">
Aber eigentlich schert sich der IE nix um Mimetypes. Es hängt wohl doch eher mit der Verknüpfung zusammen.
Grüße,
Jochen
Hello,
Nun bekomme ich aber auf dem Client das Downloadfenster angezeigt. Wieso?
Ich habe hier leider kein Win98 zum ausprobieren. Gab es da nicht irgendwie die Möglichkeit den Mimetype zu beeinflussen? Oder du versuchst es mit:
<a href="diedatei.php" type="text/html">
Nette Idee eigentlich. Gibts aber wohl nicht.
Aber eigentlich schert sich der IE nix um Mimetypes. Es hängt wohl doch eher mit der Verknüpfung zusammen.
Er kann ihn aber nicht erkennen.
Ich habe es jetzt erstmal durch Hinzufügen des <pre>-Tags gelöst.
<pre>Das Dateihandle lautet: Resource id #2</pre>
Eigentlich besteht ja auch noch meine Frage an die DEVs, ob ich der Ordnung halber immer vollständige HTML-Ausgaben darstelle, also mit DocType und "Gedöns"
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Moin!
Im Verzeichnis der HTML-Datei des Artikels, den ich schreibe, liegt auch eine *.php-Datei. Über den Link "Anzeigebeispiel: So sieht's aus" ist sie verlinkt. Natürlich kann sie nicht ausgeführt werden. Sie enthält auch in Wirklichkeit nur das Ergebnis des Codes, dass die dazugehörige "echte" PHP-Datei erzeugen würde.
Nun bekomme ich aber auf dem Client das Downloadfesnter angezeigt. Wieso?
Im Nicht-HTTP-Kontext gibt es keinen HTTP-Header, welcher den Content-Typ angibt. Der Browser muß sich also anderweitig behelfen, und das bedeutet: Dateiendung zu Hilfe nehmen. Die lautet ".php" und ist mit Textpad verknüpft - das ist nichts, was ein Browser mit Glück in "das zeige ich mal als HTML an" umbiegen könnte.
Auf dem Server und online sieht das aber vollkommen anders aus! Da gibts einen HTTP-Header, und egal, ob die Datei nun ".html" oder ".php" heißt, sie wird mit einer dieser beiden Endungen als "text/html" ausgeliefert - einmal direkt, einmal durch den PHP-Interpreter.
Ich wäre jetzt nicht irritiert, wenn eine andere Fake-Datei (auch eine *.php) nicht wie erwartet angezeigt werden würde. Die beginnt allerdings auch mit einem gültigen Tag. (<br>)
Der IE sucht in Dateien, deren Content-Typ er nicht kennt, oder die "verdächtig" sind, den Inhalt nach Anhaltspunkten ab. Das Vorhandensein eines HTML-Tags ist offenbar ein Indiz, dass es sich um HTML handeln könnte, während die Abwesenheit sämtlicher HTML-Indikatoren zum "Download" führt.
Online wird sich deine Datei aber komplett anders verhalten, weil "text/html" ein bekannter und unverdächtiger Content-Typ ist.
- Sven Rautenberg
Hello Sven,
Im Nicht-HTTP-Kontext gibt es keinen HTTP-Header, welcher den Content-Typ angibt. Der Browser muß sich also anderweitig behelfen, und das bedeutet: Dateiendung zu Hilfe nehmen. Die lautet ".php" und ist mit Textpad verknüpft - das ist nichts, was ein Browser mit Glück in "das zeige ich mal als HTML an" umbiegen könnte.
Auf dem Server und online sieht das aber vollkommen anders aus! Da gibts einen HTTP-Header, und egal, ob die Datei nun ".html" oder ".php" heißt, sie wird mit einer dieser beiden Endungen als "text/html" ausgeliefert - einmal direkt, einmal durch den PHP-Interpreter.
Online wird sich deine Datei aber komplett anders verhalten, weil "text/html" ein bekannter und unverdächtiger Content-Typ ist.
Ja, so hatte ich mir das auch zusammengereimt und wollte gerade den Vorschlag notieren, im Netzverzeichnis für den Artikel später einfach AddType oder ForceType zu nutzen. Aber da viel mir dann ein, dass es ja auch mal eine Offlineversion von Artikeln geben könnte. Und da mir der Umzug gezeigt hat, wie lange es dauert, bis Pfade und Links usw. wieder passen, denek ich, es wäre besser, es gleich "nachhaltig" zu lösen.
Bleibt jetzt erstmal noch die Frage: Alle PHP-Scriptchen immer mit Doctype und "Gedöns"? Oder genauso weiter falsch machen, wie es fast alle Tuts und Books tun?
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Hello,
mal was Meschliches...
[...]Netzverzeichnis für den Artikel später einfach AddType oder ForceType zu nutzen. Aber da viel mir dann ein, [...]
Bei der Betrachtung dieser Zeile fällt mir noch mehr ein *gg*
Aber ich beobachte das schon eine ganze Weile bei mir. Obwohl ich nicht darüber nachdenke und es bewusst weiß, dass "fiel mir ein" nicht von "viel falsch" kommt, schreiben die Finger das einfach so. Das Phänomen gibt es auch bei anderen Isophonen. Wenn ich es dann selber lese, läuft mir immer die Schamröte ins Gesicht. Ist das mein persönliche Phänomen oder ist das was "freudsches bekanntes"?
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Moin!
Bleibt jetzt erstmal noch die Frage: Alle PHP-Scriptchen immer mit Doctype und "Gedöns"? Oder genauso weiter falsch machen, wie es fast alle Tuts und Books tun?
Ich würde meinen: Genau so ausgeben, wie das Skript es tun würde. Wenn dein Skript DOCTYPEs ausgibt, gehören die mit rein, ansonsten nicht.
- Sven Rautenberg
Hello,
Bleibt jetzt erstmal noch die Frage: Alle PHP-Scriptchen immer mit Doctype und "Gedöns"? Oder genauso weiter falsch machen, wie es fast alle Tuts und Books tun?
Ich würde meinen: Genau so ausgeben, wie das Skript es tun würde. Wenn dein Skript DOCTYPEs ausgibt, gehören die mit rein, ansonsten nicht.
Darf ich Dich demnächst Salomon nennen?
Ist aber leider noch keine Lösung, denn die Frage ist doch, ob in die Musterscripte diese Ausgabeanweisungen hineingehören.
Oder dürfen neuerdings(?) nach W3 HTML-Seiten ohne jegliche Körperangaben oder den Doctype gesendet werden?
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Moin!
Darf ich Dich demnächst Salomon nennen?
"Sven" würde reichen. :)
Ist aber leider noch keine Lösung, denn die Frage ist doch, ob in die Musterscripte diese Ausgabeanweisungen hineingehören.
Das hängt doch davon ab, was man bezweckt. Sofern man die EVA-Methoden streng anwendet, können zum Zeitpunkt des Fehlers noch keinerlei HTML-Ausgaben aufgetreten sein, also wird die Fehlermeldung logischerweise "nackt" zum Browser übertragen werden.
Schlägt hingegen erst die Template-Engine oder die Ausgabe fehl, oder klappt gar alles, ist logischerweise von der Existenz von HTML-Fragmenten, beginnend mit einem DOCTYPE, auszugehen.
Oder dürfen neuerdings(?) nach W3 HTML-Seiten ohne jegliche Körperangaben oder den Doctype gesendet werden?
Die Intention eines jeden Skriptes sollte es sein, erstens fehlerfrei und zweitens validen HTML-Code liefernd zu arbeiten.
Wenn du Intention 1 schon mutwillig zu Demonstrationszwecken ignorierst, kannst du kaum noch Intention 2 erfüllen.
- Sven Rautenberg
Hello,
Die Intention eines jeden Skriptes sollte es sein, erstens fehlerfrei und zweitens validen HTML-Code liefernd zu arbeiten.
Wenn du Intention 1 schon mutwillig zu Demonstrationszwecken ignorierst, kannst du kaum noch Intention 2 erfüllen.
Da ist was Wahres dran. Bei den Scripten, die ohnehin nur zur Ausgabe von Fehlermeldungen entstehen, ist es nicht sehr sinnvoll. Der Code lenkt ja auch vom wesentlichen Konstrukt ab.
Allerdings habe ich immer die Intention, Fehlermeldung selber abzufangen und zu sammeln und dann erst gezielt auszugeben, dann natürlich auf einer validen Seite. Aber das wäre ein ganz anderes Thema.
Diese Konstrukionen mit "... or die();" sind zwar für den Testbetrieb ganz gut, aber nicht für den laufenden - finde ich.
Ich werde es also im wesentlichen auf den php-Code beschränken, aber mit Hinwei, wie es eigentlich aussehen müsste. Sind ja auch nicht sooo viele Scripte in diesem Artikel drin. Nur es folgen andere Ausarbeitungen, und da soll man sich doch nicht gleich schlechten Stil angewöhnen.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom