include("http://..."); => Was mach ich falsch?

[S.Goertz]

Hallo,

Bei der Anwendung des include()-Befehls mit einer Datei, die sich auf einem anderen Server befindet, kommt es immer zu einem Fehler. Die Datei kann nicht included werden. Selbst wenn sich die Datei auf demselben Server befindet, wie das Hauptscript, aber mit http:// angegeben wird, gibt es diese Fehlermeldung.

Ist es grundsätzlich nicht möglich, mit include() Dateien mit http://-Pfad zu includen, oder muss nur etwas anders konfiguriert werden? gibt es einen anderen Befehl, der dies ermöglicht?

Ziel ist es, dass ein verkauftes Programm zur Registrierung einmaligen Kontakt mit unserem Server aufnimmt.

Gruß,
  S.Goertz

[Philipp Hasenfratz]

Halihallo S.

Bei der Anwendung des include()-Befehls mit einer Datei, die sich auf einem anderen Server befindet, kommt es immer zu einem Fehler. Die Datei kann nicht included werden. Selbst wenn sich die Datei auf demselben Server befindet, wie das Hauptscript, aber mit http:// angegeben wird, gibt es diese Fehlermeldung.

Soll auch, include ist nur für das includen von Dateien zuständig, die sich auf dem
lokalen Dateisystem befinden.

Ist es grundsätzlich nicht möglich, mit include() Dateien mit http://-Pfad zu includen, oder muss nur etwas anders konfiguriert werden? gibt es einen anderen Befehl, der dies ermöglicht?

Nein.

Ziel ist es, dass ein verkauftes Programm zur Registrierung einmaligen Kontakt mit unserem Server aufnimmt.

Man verwende normale HTTP-Zugriffe, wie z. B. das Verwenden von open (dort ist es möglich
mit http:// externe Ressourcen zu laden) oder Socket-Verbindungen.

Viele Grüsse

Philipp

[Benjamin Wilfing]

Hallo Philipp,

Ist es grundsätzlich nicht möglich, mit include() Dateien mit http://-Pfad zu includen, oder muss nur etwas anders konfiguriert werden? gibt es einen anderen Befehl, der dies ermöglicht?

Nein.

Doch: http://www.php.net/manual/de/features.remote-files.php.

Allerdings, wie man unter genanntem Link nachlesen kann, funktioniert das Einbinden von entfernten Dateien per include() oder require() nicht unter Windows. Da muss dann auf die Dateifunktionen zurückgegriffen werden.

Man verwende normale HTTP-Zugriffe, wie z. B. das Verwenden von open (dort ist es möglich
mit http:// externe Ressourcen zu laden) oder Socket-Verbindungen.

Die lassen sich ja trotzdem verwenden, die Frage ist, was sinnvoller/sicherer ist. Das kann ich allerdings nicht beantworten (würde mich aber durchaus interessieren).

Grüße aus Darmstadt,
Benjamin

[Philipp Hasenfratz]

Halihallo Benjamin

Ist es grundsätzlich nicht möglich, mit include() Dateien mit http://-Pfad zu includen, oder muss nur etwas anders konfiguriert werden? gibt es einen anderen Befehl, der dies ermöglicht?

Nein.

Doch: http://www.php.net/manual/de/features.remote-files.php.

Danke.

Allerdings, wie man unter genanntem Link nachlesen kann, funktioniert das Einbinden von entfernten Dateien per include() oder require() nicht unter Windows. Da muss dann auf die Dateifunktionen zurückgegriffen werden.

Dateifunktionen? - Dass man Internetressourcen in PHP wie Dateien öffnen kann, ist
lediglich ein Feature oder Bug. Mir gefallen Socket oder INET-Funktionen besser ;)

Man verwende normale HTTP-Zugriffe, wie z. B. das Verwenden von open (dort ist es möglich
mit http:// externe Ressourcen zu laden) oder Socket-Verbindungen.

Die lassen sich ja trotzdem verwenden, die Frage ist, was sinnvoller/sicherer ist. Das kann ich allerdings nicht beantworten (würde mich aber durchaus interessieren).

Sicherheit bzgl. include oder fopen? - Die greifen ja auf denselben Wrapper zurück,
folglich werden sie gleich (un-)sicher sein; folgere ich zumindest aus deiner verlinken
Doku.

Viele Grüsse

Philipp

[Benjamin Wilfing]

Hallo Philipp,

Dateifunktionen? - Dass man Internetressourcen in PHP wie Dateien öffnen kann, ist
lediglich ein Feature oder Bug. Mir gefallen Socket oder INET-Funktionen besser ;)

Hm, die habe ich mir noch nicht so wirklich zu Gemüte gezogen, geschweige denn, mal eingesetzt. Das werde ich aber demnächst mal tun - hört sich ganz interessant an. Danke auch dir für den Tipp :-)

Sicherheit bzgl. include oder fopen? - Die greifen ja auf denselben Wrapper zurück,
folglich werden sie gleich (un-)sicher sein; folgere ich zumindest aus deiner verlinken
Doku.

Ja, das klingt irgendwie logisch und überzeugend :-).

Grüße aus Darmstadt,
Benjamin

[Andreas Korthaus]

Hallo!

Doch: http://www.php.net/manual/de/features.remote-files.php.

Danke.

Allerdings, wie man unter genanntem Link nachlesen kann, funktioniert das Einbinden von entfernten Dateien per include() oder require() nicht unter Windows. Da muss dann auf die Dateifunktionen zurückgegriffen werden.

Ab PHP 4.3.0 auch unter Windows: http://www.php.net/manual/en/features.remote-files.php

Dateifunktionen? - Dass man Internetressourcen in PHP wie Dateien öffnen kann, ist
lediglich ein Feature oder Bug. Mir gefallen Socket oder INET-Funktionen besser ;)

Wieso? Ich habe das ehrlich gesagt noch nie verwendet, verstehe aber auch nicht ganz warum alle PERL-"Freaks" dagegen wettern. Der Programmierer will eine Datei einbinden, dies kann er auf vielfältige Weise tun, über das lokale Filesystem, Datei per HTTP, FTP... runterladen und einlesen... was spricht dagegen dass das ganze halt etwas vereinfacht wird? Sicher, "Ihr" habt das anders gelernt, ich auch, aber trotzdem verstehe ich nicht warum diese Vereinfachung schlecht sein soll?!

Die lassen sich ja trotzdem verwenden, die Frage ist, was sinnvoller/sicherer ist. Das kann ich allerdings nicht beantworten (würde mich aber durchaus interessieren).

Sicherheit bzgl. include oder fopen? - Die greifen ja auf denselben Wrapper zurück,
folglich werden sie gleich (un-)sicher sein; folgere ich zumindest aus deiner verlinken
Doku.

include() code wird vom PHP-Parser geparst. Wenn darin jetzt sreht <?php system("rm -r "); ?> (oder sowas) dann ist das sicher nicht lustig, udn wenn dann so Spezialisten eine Variable die sie per GET übergeben includen, dann viel Spaß ;-)
fopen() wird normalerweise mit fgets() oder file() gelesen, das was gelesen wird wird aber nur in eine Variable geschrieben oder höchtens ausgegeben, aber nicht geparst.
Ansonsten hast Du Rech bzgl. des Wrappers.

Viele Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

Dateifunktionen? - Dass man Internetressourcen in PHP wie Dateien öffnen kann, ist
lediglich ein Feature oder Bug. Mir gefallen Socket oder INET-Funktionen besser ;)
Wieso? Ich habe das ehrlich gesagt noch nie verwendet, verstehe aber auch nicht ganz warum alle PERL-"Freaks" dagegen wettern. Der Programmierer will eine Datei einbinden, dies kann er auf vielfältige Weise tun, über das lokale Filesystem, Datei per HTTP, FTP... runterladen und einlesen... was spricht dagegen dass das ganze halt etwas vereinfacht wird? Sicher, "Ihr" habt das anders gelernt, ich auch, aber trotzdem verstehe ich nicht warum diese Vereinfachung schlecht sein soll?!

OK, diese Argumentation lass ich auch gelten ;)
Meine lautet so:
Internetressourcen haben mit Dateien nix gemein. Nichteinmal das Transportmedium
(Socket <=> Speicher) ist das selbe. Wie um alles in der Welt kommen die Entwickler
von PHP drauf, diese komplett verschiedenen Anwendungen zu vereinen (Zugegeben, _einige_
Module von Perl machen _genau_ das selbe, wie z. B. LWP!). Es kommt doch auch kein
Mensch auf die Idee, die Funktion time wahlweise mittels HEAD-Request auf eine Atomuhr-
Server oder aber über die Timestamp im RAM abzufragen (time() oder time
('http:://www.atomclock.com')). Hm... Wobei??? - Eigentlich gar nicht übel... ;)
Aber nein! - Ich bleibe hart! - Äpfel und Birnen mischt man nicht! ;-)

Nun, ich habe gar nicht soviel gegen diese Funktionalität, ich meide sie nur, da es
für mich Stilbruch wäre. Einigen wir uns: beide haben recht.

include() code wird vom PHP-Parser geparst. Wenn darin jetzt sreht <?php system("rm -r "); ?> (oder sowas) dann ist das sicher nicht lustig, udn wenn dann so Spezialisten eine Variable die sie per GET übergeben includen, dann viel Spaß ;-)
fopen() wird normalerweise mit fgets() oder file() gelesen, das was gelesen wird wird aber nur in eine Variable geschrieben oder höchtens ausgegeben, aber nicht geparst.
Ansonsten hast Du Rech bzgl. des Wrappers.

ACK.

Viele Grüsse

Philipp

[Andreas Korthaus]

Hallo Philipp!

Meine lautet so:

na lass mal hören ;-)

Internetressourcen haben mit Dateien nix gemein. Nichteinmal das Transportmedium
(Socket <=> Speicher) ist das selbe. Wie um alles in der Welt kommen die Entwickler
von PHP drauf, diese komplett verschiedenen Anwendungen zu vereinen?

Nun ich denek das kommt daher das man sich überlegt was will der Programmierer mit include() erreichen. Er will eine Datei in den aktuellen PHP-Code einbinden, das heißt das der Parser das was in der einzubindenen Datei steht parsen soll. Kann es mir als Programmierer nicht sch... egal sein wo die Datei liegt und wo sie herkommt?  include() ist dann halt so intelligent und erkennt auf welchem Weg es an die Datei kommt, wieso soll ich als Programmierer das jedesmal aufs neue implementieren, vermutlich jedesmal erheblich fehleranfälliger und schlechter als es jetzt in PHP fertig implementiert ist?
Du hast Recht, das was PHP da macht ist was völlig anderes. Es ist aber vermutlich auch was völig anderes in Windows eine Datei zu öffnen als unter Unix, oder? Wieso wird das nicht unterschieden? Wieso greift man nicht direkt auf die Systemfunktionen zurück sondern verwendet eigene "Proprietäre" programmierungen der benutzen Programmiersprache? Einfach daher weil das zum einen viel zu kompliziert wäre, und vor allem da das verschieden ist und man sich so nicht alle Systemeigenheiten merken muss... sowas ähnliches macht PHP jetzt halt auf einer höheren Ebene.

Es kommt doch auch kein
Mensch auf die Idee, die Funktion time wahlweise mittels HEAD-Request auf eine Atomuhr-
Server oder aber über die Timestamp im RAM abzufragen (time() oder time
('http:://www.atomclock.com')). Hm... Wobei??? - Eigentlich gar nicht übel... ;)
Aber nein! - Ich bleibe hart! - Äpfel und Birnen mischt man nicht! ;-)

Der Unterschied ist das mir der HTTP-Request eine Datei anfordert, genau so wie die Funktionen innheralb des lokalen Dateisystems.

Nun, ich habe gar nicht soviel gegen diese Funktionalität, ich meide sie nur, da es
für mich Stilbruch wäre. Einigen wir uns: beide haben recht.

OK, und ich verwende es ja auch gar nicht und werdees auch nich verwendenda zu unflexibel, trotzdem finde ich es nicht schlecht ;-)

Grüße
Andreas

[Sven Rautenberg]

Moin!

Internetressourcen haben mit Dateien nix gemein. Nichteinmal das Transportmedium (Socket <=> Speicher) ist das selbe. Wie um alles in der Welt kommen die Entwickler von PHP drauf, diese komplett verschiedenen Anwendungen zu vereinen (Zugegeben, _einige_ Module von Perl machen _genau_ das selbe, wie z. B. LWP!).

Ich würde sagen, dass Unix dran schuld ist. Eine Maxime dort lautet: "Alles ist Datei". Und folgerichtig kannst du nicht nur normale Dateien öffnen und schließen, sondern auch komplette Partitionen (z.B. /dev/hda1), komplette Festplatten (/dev/hda), serielle Schnittstellen (/dev/tty1), den gesamten Hauptspeicher (/proc/kcore), diverse Eigenschaften aller laufenden Programme (/proc/123/*), und so weiter...

Es ist deshalb nur gerecht, wenn PHP auch HTTP und FTP-Ressourcen als Datei behandelt. Denn auch fsockopen() liefert nur eine Dateiressourcenpointer zurück, das Lesen und Schreiben funktioniert dann mit den üblichen Dateifunktionen.

Es kommt doch auch kein Mensch auf die Idee, die Funktion time wahlweise mittels HEAD-Request auf eine Atomuhr-Server oder aber über die Timestamp im RAM abzufragen (time() oder time ('http:://www.atomclock.com')). Hm... Wobei??? - Eigentlich gar nicht übel... ;)

Wenn schon, dann würde die Zeit mittels Timeserver-Protokoll abgefragt werden. ;)

Und die Idee ist durchaus nicht doof.

- Sven Rautenberg

[Philipp Hasenfratz]

Halihallo Sven

Ich würde sagen, dass Unix dran schuld ist. Eine Maxime dort lautet: "Alles ist Datei". Und folgerichtig kannst du nicht nur normale Dateien öffnen und schließen, sondern auch komplette Partitionen (z.B. /dev/hda1), komplette Festplatten (/dev/hda), serielle Schnittstellen (/dev/tty1), den gesamten Hauptspeicher (/proc/kcore), diverse Eigenschaften aller laufenden Programme (/proc/123/*), und so weiter...

ACK.

Es ist deshalb nur gerecht, wenn PHP auch HTTP und FTP-Ressourcen als Datei behandelt. Denn auch fsockopen() liefert nur eine Dateiressourcenpointer zurück, das Lesen und Schreiben funktioniert dann mit den üblichen Dateifunktionen.

Ja. Deine Argumentation ist sehr überzeugend und richtig. Eigentlich bin ich im Begriff
euch beiden gar zuzustimmen; als ich mich etwas durch die libc gelesen habe, ist mir
aufgefallen, dass diese Technik sehr wohl sehr schön und durchdacht ist. Ich war und
bin noch immer auf dem Standpunkt fixiert, dass man verschiedene Sachen eben nicht
mischen soll (das geht wohl jedem OOP-Programmierer so), aber hier ist dies gar nicht
der Fall. Im Gegenteil: die libc und Unix Verfahren genau danach: Was haben Sockets,
Dateien, Speichert etc. gemeinsam? - Sie sind sequentiell ausles- und beschreibbar,
das libc Streaming ist geboren. Somit ist das Streaming eine Superklasse von Datei und
Socket (analog zu OOP formuliert), was genau meinem Wunsch entspricht ;-)
Gut, die Argumentation ist Lückenhaft, ich bin auch noch etwas am Schwanken, was die
Meinungsbildung diesbezüglich angeht; bisher kann ich eigentlich mit beiden Meinungen
anfreunden.

Es kommt doch auch kein Mensch auf die Idee, die Funktion time wahlweise mittels HEAD-Request auf eine Atomuhr-Server oder aber über die Timestamp im RAM abzufragen (time() oder time ('http:://www.atomclock.com')). Hm... Wobei??? - Eigentlich gar nicht übel... ;)

Wenn schon, dann würde die Zeit mittels Timeserver-Protokoll abgefragt werden. ;)

FULL ACK.. ;)

Und die Idee ist durchaus nicht doof.

Ihr Lob ehrt mich, Ihre Kritik bringt mich weiter! - Wo hatte ich eine doofe Idee?

Viele Grüsse

Philipp