Prüfen. ob URL vorhanden - Problem

[Urmel]

Hi,

eine Webseite verlinkt zu (Link kopiert)
http://www.shanty-chor-kieler-foerde.de/Kieler%20Foerde.mp3

Wenn ich das in die Adresszeile des Browsers kopiere, startet der Download wie erwartet.

Aber in PHP macht's Probleme:

  
$url = 'http://www.shanty-chor-kieler-foerde.de/Kieler%20Foerde.mp3';  
if ( file_exists( $url )) echo $url." erreichbar\n"; else echo $url." nicht zu finden\n";  
$url = urlencode( $url );  
if ( file_exists( $url )) echo $url." erreichbar\n"; else echo $url." nicht zu finden\n";  
  
$url = 'http://www.shanty-chor-kieler-foerde.de/Kieler Foerde.mp3';  
if ( file_exists( $url )) echo $url." erreichbar\n"; else echo $url." nicht zu finden\n";  
$url = urlencode( $url );  
if ( file_exists( $url )) echo $url." erreichbar\n"; else echo $url." nicht zu finden\n";  

Ergebnis:
http://www.shanty-chor-kieler-foerde.de/Kieler%20Foerde.mp3 nicht zu finden
http%3A%2F%2Fwww.shanty-chor-kieler-foerde.de%2FKieler%2520Foerde.mp3 nicht zu finden
http://www.shanty-chor-kieler-foerde.de/Kieler Foerde.mp3 nicht zu finden
http%3A%2F%2Fwww.shanty-chor-kieler-foerde.de%2FKieler+Foerde.mp3 nicht zu finden

Trotz des Leerzeichens kann ich die Datei herunterladen und mit dem mp3-Player abspielen. Aber wieso kommt PHP nicht an sie heran?

Gruß, Urmel

[T-Rex]

Ganz einfach, das ist eine URL und keine Datei.
du hast keinen Zugriff auf das Dateisystem direkt, deshalb kannst du auch nicht per file_exstis prüfen ob die Datei vorhanden ist. Was du machst ist eine Anfrage via url an den Webserver, der hat Zugriff auf das Dateisystem und kann dir eine Datei liefern.

Was du jedoch machen kannst, du kannst den Header abfragen ob die Anfrage erfolgreich war. Eine 200 Meldung sollte da im Idealfall und eine 404 im schlimmsten Fall kommen.

Wie prüfe ich den Header ab fragst du?
Dann ist das hier das richtige für dich:
http://de2.php.net/manual/de/book.curl.php

Gruß
200
T-Rex

[Urmel]

Hi, T-Rex,

danke für den Link, werde ich durchlesen.

Ich habe einfach was verwexelt:
$datei = file( 'http://...' );
funzt, damit funzt
file_exists( 'http;//...' ) aber noch lange nicht. Kann man ja nicht ahnen.

So geht's aber:

if ( $handle = fopen( $url, 'r' )) fclose( $handle );
    else $url_nicht_vorh = TRUE;

Gruß, Urmel

[Jonny 5]

Hi Urmel,

Hi, T-Rex,

danke für den Link, werde ich durchlesen.

Ich habe einfach was verwexelt:
$datei = file( 'http://...' );
funzt, damit funzt
file_exists( 'http;//...' ) aber noch lange nicht. Kann man ja nicht ahnen.

So geht's aber:

if ( $handle = fopen( $url, 'r' )) fclose( $handle );
    else $url_nicht_vorh = TRUE;

Gruß, Urmel

Falls du PHP5 verwendest, könntest du um sicherer zu sein, daß es sich auch um den richtigen Typ handelt doch die dafür vorgesehene Funktion get_headers verwenden.

Man könnte dann zb mit einem regulären Ausdruck prüfen, ob die Antwort des Servers korrekt war:

var_dump(count(preg_grep('~200 OK|audio~',get_headers($url)))==2);

Prüft, ob die vom Server gesendeten Response Header einen 200er Status und "audio" enthalten.

Viele Grüße,
Jonny 5

[fastix®]

Moin!

So geht's aber:

if ( $handle = fopen( $url, 'r' )) fclose( $handle );
    else $url_nicht_vorh = TRUE;

Naja... ist es Dein Server?

wenn nicht würde ich mit ini_get('allow_url_fopen') erst mal prüfen, ob das Abholen externer Ressourcen so überhaupt erlaubt ist.

Falls das vom Hoster verboten wurde (das kommt SEHR oft vor), steht dennoch häufig curl zur Verfügung:

Prüfe mit function exists('curl_init') ob curl installiert ist.

Den Rest kannst hier nachlesen: http://php.net/manual/de/book.curl.php

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[dedlfix]

Hi!

wenn nicht würde ich mit ini_get('allow_url_fopen') erst mal prüfen, ob das Abholen externer Ressourcen so überhaupt erlaubt ist.
Prüfe mit function exists('curl_init') ob curl installiert ist.

Mit phpinfo() kann man beides zugleich prüfen. Zudem hat man oftmals schon ein phpinfo-Script rumliegen. Und bevor man curl anwirft, sollte man testen, ob von den genannten leichteren Alternativen eine zur Verfügung steht (get_headers() beispielsweise).

Lo!

[fastix®]

Moin!

Mit phpinfo() kann man beides zugleich prüfen.

Nun, wir wissen nicht wofür das Skript geschrieben werden soll. Programmierung (1) für einen bestimmten Host oder (2) soll das Skript ganz allgemein auf den Markt. phpinfo() entfällt wohl im Fall 2, weil man die Prüfung in das Skript integrieren muss. Freilich kann man die Ausgaben von phpinfo() auch dann selbst (primitiv) parsen - aber Sinn macht freilich das nicht.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[dedlfix]

Hi!

Ganz einfach, das ist eine URL und keine Datei.

So einfach ist es nun auch wieder nicht. Du vergisst die "Einfachheit" PHPs, das für Funktionen, die eigentlich für das Dateisystem vorgesehen sind, ein paar Wrapper zur Verfügung stellt, die im Hintergrund die für die angefragte Ressource passende Aktion vornehmen - wenn der Wrapper das unterstützt. Und da liegt der Hase im Pfeffer begraben. Für file_exists() wird das Attribut "Supports stat()" benötigt. Beim http-Wrapper steht jedoch ein "No". Das hätte nicht unbedingt so sein müssen, denn PHP könnte ja einen HEAD-Request auf die Ressource absenden und true bei 200, anderenfalls false liefern. Möglicherweise hat man das jedoch gelassen, weil der Server ja bei HEAD ein anderes Ergebnis als bei GET senden könnte, was zu Verwirrung führen könnte.

Apropos HEAD. Wenn man mal annimmt, dass HEAD erwartungsgemäß funktioniert, kann man ja mit etwas mehr Aufwand einen HEAD-Request senden. Dazu kann man file_get_contents() nehmen (ja, auch wieder eine File-Funktion). Dem übergibt man eine vorher erstellte Context-Ressource im dritten Parameter, bei der nur für http die Option method mit HEAD befüllt wird. Wie das mit dem Context geht, bekommt man im Handbuch erklärt, wenn man den passenden Links folgt.

file_get_contents() liefert nun zwei mögliche Ergebnisse, eins im Gut-Fall, eins im Schlecht-Fall. Die probiert man beide und schaut sich jeweils mit var_dump() an, was geliefert wird. Außerdem gibt es noch die vordefinierte Variable $http_response_header, die man nach einer solchen Operation abfragen kann, um sich die HTTP-Header der Response anzuschauen. Das macht sich gut beim Debugging.

Lo!

[Tom]

Hello dedlfix,

im ersten Moment wollte ich Dir ein "fachlich hilfreich" geben, aber dann dachte ich, dass Dein Tipp nur ein halbes "fachlich hilfreih" wert ist - und das kann man hier nicht geben.

Begründung:

file_get_contents() ermöglicht über das von Dir erwähnte Funktionsargument zwar inzwischen eine Parametrisierung der Datenanforderung, aber man muss dazu ziemlich genau wissen, welche Parameter denn was überhaupt bewirken. Außerdem sind spezielle Statusabfragen mit den Namensbasierten Funktionen immer noch noch nicht möglich.

Die PHP-Leute haben hier ursprünglich eine geschlossene, für die Praxis relativ unbrauchbare Funktion geschaffen und diese dann "durch die Hintertür" wieder "aufgebohrt".

Um zu verstehen, was da eigentlich passieren soll, muss man dann doch mal selber

fsockopen()  http://de2.php.net/manual/de/function.fsockopen.php
und
    fwrite()     http://de2.php.net/manual/de/function.fwrite.php
und
    fread()...   http://de2.php.net/manual/de/function.fread.php

und ihre ganzen nativen Geschwister
mit den passenden Timeout- und Locking-Parametern benutzt haben.

Dann wird einem der Vorgang klar, der gebaut werden soll. Und dann kann man sich auch denken, welche Parameter denn das Attribut "Ressource-Context" der namensbasierten Funktion file_get_contents() denn verschlucken will, um ein ähnlich gutes Ergebnis zu liefern.

Man kann dann gezielt danach suchen, wie man das in den Ressource-Kontext reinfummeln muss...

Ein ganzes oder sogar doppeltes "fachlich hilfreich" möchte ich Dir daher für dieses Thema erst dann geben, wenn Du dich dazu durchgerungen hast, die namensbasierten Funktionen für den Produktivbetrieb von vornherein abzulehnen und gleich auf die generischen Handlefunktionen zu verweisen. Die gestatten eine (relativ gute) Kontrolle von Aktio und Reaktio und sie sind so fein gelgliedert in ihrer Aufgabe, dass man als Programmierer noch verstehen kann, was passieren soll.

Sie wären sicherlich noch beseer, wenn sie keine obskuren Fehlertexte (in $php_errmsg) erzeugen würden, sondern eine eindeutige Fehlernummer in einer noch fehlenden Systemvariable oder besser -Funktion.

Aber um das bei den PHP-Entwicklern durchzusetzen, muss ich selber wahrscheinlich noch 100 Jahre kämpfen, oder mal ein paar Millionen locker machen...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[ChrisB]

Hi,

file_get_contents() ermöglicht über das von Dir erwähnte Funktionsargument zwar inzwischen eine Parametrisierung der Datenanforderung, aber man muss dazu ziemlich genau wissen, welche Parameter denn was überhaupt bewirken.

Man muss also wissen, was man tut.
Erscheint dir das ungewöhnlich?

Außerdem sind spezielle Statusabfragen mit den Namensbasierten Funktionen immer noch noch nicht möglich.

Was soll denn bitte eine „namensbasierte“ Funktion sein?

Ein ganzes oder sogar doppeltes "fachlich hilfreich" möchte ich Dir daher für dieses Thema erst dann geben, wenn Du dich dazu durchgerungen hast, die namensbasierten Funktionen für den Produktivbetrieb von vornherein abzulehnen und gleich auf die generischen Handlefunktionen zu verweisen.

Jetzt vermisse ich das „nicht hilfreich“ wieder, weil du dafür eins verdient hättest.

MfG ChrisB

[Tom]

Hello,

Was soll denn bitte eine „namensbasierte“ Funktion sein?

Ach entschuldige bitte. Das kannst Du ja nicht wissen. Du fragst ja nie nach dem Hintergrund. Du bölkst ja immer nur los - insbesondere, wenn Du mich angreifen willst. Aber bitte, mach doch einfach.

Den Unterschied zwischen handle- und namensbasierten Funktionen könnte man z.B. hier im Archiv oder bei Goolge nachlesen, aber das wird Dir bestimmt zu mühevoll sein?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[ChrisB]

Hi,

Was soll denn bitte eine „namensbasierte“ Funktion sein?

Ach entschuldige bitte. Das kannst Du ja nicht wissen. Du fragst ja nie nach dem Hintergrund.

Tue ich doch gerade.

Den Unterschied zwischen handle- und namensbasierten Funktionen könnte man z.B. hier im Archiv oder bei Goolge nachlesen, aber das wird Dir bestimmt zu mühevoll sein?

Eine kurze Google-Suche durchs Forenarchiv scheint mir zu dem Begriff ausschließlich Treffer zu bringen, die von *dir* stammen.
Das bestätigt meinen Verdacht, dass es sich hierbei wieder mal um einen von dir erfundenen „Fachbegriff“ handelt.

Kann es also sein, dass du das nicht näher erklären magst, weil du dir bewusst bist, dass es sich wieder mal nur um heiße Luft aus deinem Munde handelt?

MfG ChrisB

[Tom]

Hello,

Eine kurze Google-Suche durchs Forenarchiv scheint mir zu dem Begriff ausschließlich Treffer zu bringen, die von *dir* stammen.

Ich habe ja gesagt, dass es Dir zuviel Mühe machen wird.

Das bestätigt meinen Verdacht, dass es sich hierbei wieder mal um einen von dir erfundenen „Fachbegriff“ handelt.

Erstens: was wäre daran so schlimm?
Zweitens: nimm ein gutes Buch über Programmierung aus der Zeit vor 1995 zur Hand, und suche darin. Dass das Wissen schon etwas älter ist, macht es in diesem Falle nicht obsolet. Es zeigt jetzt nur, dass Entwickler von heute nicht mehr über Dinge nachdenken, wenn sie ihen nicht sofort aus Google entgegenspringen.
Drittens: Mitdenken wäre fein! Was könnte "namensbasiert" im Gegensatz zu "handlebasiert" denn wohl heißen bei den Dateifunktionen und was ist der Unterschied?

Du liebst doch sonst immer die Leute, die selbstständig mitdenken. DAS kannst Du doch auch, oder?

Kann es also sein, dass du das nicht näher erklären magst, weil du dir bewusst bist, dass es sich wieder mal nur um heiße Luft aus deinem Munde handelt?

Du redest wirr und bist scheinbar nicht an einer sachlichen Diskussion interessiert.

Eine namensbasierte Dateifunktion übernimmt für die Arbeit an der Datei einen _Dateinamen_ und wickelt dann alle Datenhandlungen vom ersten Zugriff bis zum letzten als geschlossene Funktion ab. An ein Handle auf die Datei lässt sie den Programmierer nicht heran. Solche Funktionen sind i.d.R. für den konkurrierenden Betrieb bzw. eine fein gegliederte Erfolgskontrolle nicht geeignet.

Eine handlebasierte Dateifunktion übernimmt genau umrissene Arbeiten und ermöglicht dem  Programmierer über das Handle zwischendurch diverse Kontrollen und weitere Aktionen mit derselben Datei. Das Handle lässt sich auch an andere Prozesse weiterreichen oder vererben.

Ein sauberes File Sharing ist mit namensbasierten Funktionen nahezu unmöglich.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[ChrisB]

Hi,

Das bestätigt meinen Verdacht, dass es sich hierbei wieder mal um einen von dir erfundenen „Fachbegriff“ handelt.

Erstens: was wäre daran so schlimm?

Es wäre vor allem mal wieder typisch für dich.

Eine namensbasierte Dateifunktion übernimmt für die Arbeit an der Datei einen _Dateinamen_ und wickelt dann alle Datenhandlungen vom ersten Zugriff bis zum letzten als geschlossene Funktion ab.

Dann zitiere ich dich jetzt mal:

Erstens: was wäre daran so schlimm?

An ein Handle auf die Datei lässt sie den Programmierer nicht heran.

Den brauche ich auch oft gar nicht.

Solche Funktionen sind i.d.R. für den konkurrierenden Betrieb bzw. eine fein gegliederte Erfolgskontrolle nicht geeignet.

Da wir hier über den Zugriff auf URLs reden, fällt dein erstes Argument ins Wasser, und dein zweites ist nicht stichhaltig, weil man das wie dedlfix schon sagte über den context-Parameter sehr wohl gut handeln kann.

Ein sauberes File Sharing ist mit namensbasierten Funktionen nahezu unmöglich.

Es geht nicht um „File Sharing“.

Du redest wirr und bist scheinbar nicht an einer sachlichen Diskussion interessiert.

Und du bläst ein an sich simples Thema mal wieder auf und verkomplizierst es unnötig. Aber das ist ja dein Spezialgebiet.

MfG ChrisB

[Tom]

Hello,

An ein Handle auf die Datei lässt sie den Programmierer nicht heran.

Den brauche ich auch oft gar nicht.

Weil Du nicht programmieren kannst ;-P

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

Ein ganzes oder sogar doppeltes "fachlich hilfreich" möchte ich Dir daher für dieses Thema erst dann geben, wenn Du dich dazu durchgerungen hast, die namensbasierten Funktionen für den Produktivbetrieb von vornherein abzulehnen und gleich auf die generischen Handlefunktionen zu verweisen. Die gestatten eine (relativ gute) Kontrolle von Aktio und Reaktio und sie sind so fein gelgliedert in ihrer Aufgabe, dass man als Programmierer noch verstehen kann, was passieren soll.

Man muss nicht immer alles von klein auf selbst entwerfen. Die volle Kontrolle benötigt man schließlich nicht in jedem Fall.

Lo!

[Tom]

Hello,

Ein ganzes oder sogar doppeltes "fachlich hilfreich" möchte ich Dir daher für dieses Thema erst dann geben, wenn Du dich dazu durchgerungen hast, die namensbasierten Funktionen für den Produktivbetrieb von vornherein abzulehnen und gleich auf die generischen Handlefunktionen zu verweisen. Die gestatten eine (relativ gute) Kontrolle von Aktio und Reaktio und sie sind so fein gelgliedert in ihrer Aufgabe, dass man als Programmierer noch verstehen kann, was passieren soll.

Man muss nicht immer alles von klein auf selbst entwerfen.

Genau. Deshalb hätten sich die PHP-Entwickler auch den Entwurd der namansbasierten Filefunktionen sparen können. Die taugen nur für "quick & dirty".

Die volle Kontrolle benötigt man schließlich nicht in jedem Fall.

Nö, für "quick & dirty" benötigt man selten einen Plan...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[ChrisB]

Hi,

Genau. Deshalb hätten sich die PHP-Entwickler auch den Entwurd der namansbasierten Filefunktionen sparen können. Die taugen nur für "quick & dirty".

Kannst du diesen Quatsch auch irgendwie argumentativ belegen?

MfG ChrisB

[Tom]

Hello,

Genau. Deshalb hätten sich die PHP-Entwickler auch den Entwurd der namansbasierten Filefunktionen sparen können. Die taugen nur für "quick & dirty".

Kannst du diesen Quatsch auch irgendwie argumentativ belegen?

Ja, da hast Du Recht. Da haben die PHP-Entwickler Quatsch gemacht.
Soweit ich das bisher festellen konnte, halten sie bei den Streams innerhalb der namensbasierten Funktionen noch nicht einmla die Forderung nach POSIX ein, dass der Stream während der Bearbeitung gesperrt sein muss. Bei einer der Funktionen (file_put_contents) ist inzwischen wenigstens ein Schalter dafür aufgetaucht. http://de.php.net/manual/en/function.file-put-contents.php

Und im übrigen lies erstmal den Artikel von Christian Seiler
http://aktuell.de.selfhtml.org/artikel/programmiertechnik/dateisperren/
und gehe in dich :-)

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

Soweit ich das bisher festellen konnte, halten sie bei den Streams innerhalb der namensbasierten Funktionen noch nicht einmla die Forderung nach POSIX ein, dass der Stream während der Bearbeitung gesperrt sein muss.

Und was genau bringt das im vorliegenden Falle einer abzufragenden HTTP-Ressource?

Lo!

[Tom]

Hello,

Soweit ich das bisher festellen konnte, halten sie bei den Streams innerhalb der namensbasierten Funktionen noch nicht einmla die Forderung nach POSIX ein, dass der Stream während der Bearbeitung gesperrt sein muss.

Und was genau bringt das im vorliegenden Falle einer abzufragenden HTTP-Ressource?

Du bist aber neugierig :-)
Und außerdem vergesslich! Das haben wir beide nämlich neulich erst diskutiert.
Den Thread darfst Du jetzt aber mal raussuchen. Ist erst ein paar Tage her!

außerdem siehe nochmals https://forum.selfhtml.org/?t=206642&m=1403253
außerdem http://de3.php.net/manual/en/function.stream-get-meta-data.php

Man kann anders nicht feststellen, WARUM die Ressource ggf. nicht erreichbar ist. Sie könnte nämlich temporär gesperrt sein. Dann funktioniert fsockopen() zwar noch fehlerfrei, man kann aber den Socket nicht lesen. Das haben wir neulich erst diskutiert. Da hast Du dann nur nicht mehr reagiert später.

Bei Verwendung der namensbasierten Version (file_get_contents()) bekommt man nur ein false. Das kann dann bedeuten, dass die Ressource nicht existiert, dass sie momentan gesperrt ist oder sonstige Fehler beim Lesen aufgetreten sind.

Wenn sie aber nur gesperrt wäre, würde sich ein späteres Nachfragen nochmal lohnen.

Wenn man die Timeouts nicht vernünftig setzt, ist irgendwann die Max-Execution Time des Scriptes erreicht, bevor der Socket oder die Leseanforderung den Abbruch verursachen. Das gilt allerdings sowohl für die handlebasierten, als auch für die namensbasierten Funktionen.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Tom]

Hello,

Und außerdem vergesslich! Das haben wir beide nämlich neulich erst diskutiert.

https://forum.selfhtml.org/?t=206470&m=1401770

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[ChrisB]

Hi,

Bei Verwendung der namensbasierten Version (file_get_contents()) bekommt man nur ein false.

Nein, man kann sehr genau auswerten, welcher HTTP-Fehler ggf. aufgetreten ist.

MfG ChrisB

[Tom]

Hello,

Bei Verwendung der namensbasierten Version (file_get_contents()) bekommt man nur ein false.

Nein, man kann sehr genau auswerten, welcher HTTP-Fehler ggf. aufgetreten ist.

Na, dann zeig mal, wie Du das machst.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[ChrisB]

Hi,

Bei Verwendung der namensbasierten Version (file_get_contents()) bekommt man nur ein false.

Nein, man kann sehr genau auswerten, welcher HTTP-Fehler ggf. aufgetreten ist.

Na, dann zeig mal, wie Du das machst.

Nein, an dieser Stelle gebe ich dir dein RTFM gerne zurück.
Das Stichwort context hast du bereits.

MfG ChrisB

[Tom]

Hello,

Bei Verwendung der namensbasierten Version (file_get_contents()) bekommt man nur ein false.

Nein, man kann sehr genau auswerten, welcher HTTP-Fehler ggf. aufgetreten ist.

Na, dann zeig mal, wie Du das machst.

Nein, an dieser Stelle gebe ich dir dein RTFM gerne zurück.
Das Stichwort context hast du bereits.

Schade, dass Du gar nicht verstehst, worum es eigentlich geht. Aber Ignoranz scheint ja leider dien Stärke zu sein.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[ChrisB]

Hi,

Schade, dass Du gar nicht verstehst, worum es eigentlich geht.

Da gibt es nicht viel zu verstehen:
Tom schwafelt mal wieder, weil er sich gern reden hört/schreiben liest.

MfG ChrisB

[Tom]

Hello,

Schade, dass Du gar nicht verstehst, worum es eigentlich geht.

Da gibt es nicht viel zu verstehen:
Tom schwafelt mal wieder, weil er sich gern reden hört/schreiben liest.

Fein, jetzt sind wir soweit. Matte frei! Wer macht den Schiedsrichter?

Du solltest dir Geld von meiner Krankenkasse auszahlen lassen, denn immer, wenn ich Deinen arroganten Unsinn lese, steigt mein Blutdruck ein wenig. Mein Arzt sagt, dass sei gut für mich ;-P

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

Bei Verwendung der namensbasierten Version (file_get_contents()) bekommt man nur ein false.
Nein, man kann sehr genau auswerten, welcher HTTP-Fehler ggf. aufgetreten ist.
Na, dann zeig mal, wie Du das machst.

Schrub ich bereits in meiner ersten Antwort in diesem Thread. Man schaue in die vordefinierte Variable $http_response_header. Ist stilistisch nicht der beste Weg, dass das so realisiert wurde, aber immerhin geht es.

Lo!

[Tom]

Hello,

Na, dann zeig mal, wie Du das machst.

Schrub ich bereits in meiner ersten Antwort in diesem Thread. Man schaue in die vordefinierte Variable $http_response_header. Ist stilistisch nicht der beste Weg, dass das so realisiert wurde, aber immerhin geht es.

Nee, das geht nicht vernünftig.

Wenn die entfernte Datei, die der Ressource zugrundeliegt, gesperrt ist, dann bekommt man aus der Funktion gar nichts, weil die solange wartet, bis sie wieder lesen kann, bzw. das Read-Timeout greift. Das ist aber üblicherweise auf "ganz schön lange" eingestellt, bzw. auf "endlos".

Die Antwort ist dann nur noch die Fehlermeldung

Fatal error: Maximum execution time of 60 seconds exceeded in
    M:\USER\TOM\WebProgTests\Xampp\dateizugriffe\download\file_get_contents.php on line 6

weil dann i.d.R. das Script-Timeout greift.

Apache berücksichtigt für die HTTP-Requests das advisory Locking des lokalen Filesystems, was ja auch richtig ist.

Üblicherweise will man in einem Script, dass entfernte Verfügbnarkeiten prüft, nicht pro Ressource 5 Sekunden oder länger warten (Read-Time-Out), bis die nächste Ressource geprüft werden kann.

Ich werde es mir jetzt mal antun, und das Read-Timeout über den Ressource-Kontext der Funktion file_get_contents() einstellen, um zu sehen, was dann passiert :-)

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[ChrisB]

Hi,

Nee, das geht nicht vernünftig.

Wenn die entfernte Datei, die der Ressource zugrundeliegt, gesperrt ist, dann bekommt man aus der Funktion gar nichts, weil die solange wartet, bis sie wieder lesen kann, bzw. das Read-Timeout greift. Das ist aber üblicherweise auf "ganz schön lange" eingestellt, bzw. auf "endlos".

Was und wann ein entfernter Webserver antwortet oder nicht antwortet, hängt nicht davon ab, wie du als Client den HTTP-Request machst.

Apache berücksichtigt für die HTTP-Requests das advisory Locking des lokalen Filesystems, was ja auch richtig ist.

Und darauf hat die „Art“ des Zugriffs, die du wählst - „namensbasiert“ vs. „handle-basiert“ - keinerlei Einfluss.

MfG ChrisB

[Tom]

Hello,

Hi,

Nee, das geht nicht vernünftig.

Wenn die entfernte Datei, die der Ressource zugrundeliegt, gesperrt ist, dann bekommt man aus der Funktion gar nichts, weil die solange wartet, bis sie wieder lesen kann, bzw. das Read-Timeout greift. Das ist aber üblicherweise auf "ganz schön lange" eingestellt, bzw. auf "endlos".

Was und wann ein entfernter Webserver antwortet oder nicht antwortet, hängt nicht davon ab, wie du als Client den HTTP-Request machst.

Apache berücksichtigt für die HTTP-Requests das advisory Locking des lokalen Filesystems, was ja auch richtig ist.

Und darauf hat die „Art“ des Zugriffs, die du wählst - „namensbasiert“ vs. „handle-basiert“ - keinerlei Einfluss.

Hast Du es denn nun wenigstens mal selber ausprobiert, oder plapperst Du nur nach, was Andere Dir vorplappern?

Selbstverständlich kann ich bei den handle-basierten Funktionen jede Schicht gezielt und einzeln auswerten, natürlich aufeinander aufbauend. Wenn der Socket nicht klappt, brauch ich gar nicht erst einen Leseversuch vorzunemehmen. Wenn aber ein Socket eröffnet werden kann, und ich dann nicht lesen kann, kann ich bei der handle-basierten Vorgehensweise den Stream-Kontext abfragen. Und der sagt mir dann, warum die Ressource nicht lesbar war.

Diese Möglichkeit stellt mir die "Schwarze-Kisten-Funktion" trotz ihrer irrwitzigen vielen Schalter und "local source populated arrays" nicht zur Verfügung. Aber vielleicht bauen die das ja auch noch ein? Dann wäre der Unsinn komplett.

Mit den diskreten Funktionen, die mit Ressource-Identifier (Handle) arbeiten, kann ich das schon immer...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

Apache berücksichtigt für die HTTP-Requests das advisory Locking des lokalen Filesystems, was ja auch richtig ist.
Und darauf hat die „Art“ des Zugriffs, die du wählst - „namensbasiert“ vs. „handle-basiert“ - keinerlei Einfluss.
Hast Du es denn nun wenigstens mal selber ausprobiert, oder plapperst Du nur nach, was Andere Dir vorplappern?

Was soll man da probieren? Ob der Apache gerade unpässlich ist oder nicht und welcher Grund auch immer dafür verantwortlich ist oder was er sonst noch so intern treibt, kann nicht über die Art der Requesterzeugung seitens des Clients gesteuert werden.

Selbstverständlich kann ich bei den handle-basierten Funktionen jede Schicht gezielt und einzeln auswerten, natürlich aufeinander aufbauend.

Nein, jede Schicht steht dir nicht zur Verfügung, da du erst oberhalb des TCP/IP-Stacks aufsetzt. Und dann kannst du grade mal noch HTTP beeinflussen, was mit dem Stream-Kontext sehr wohl auch mit den Fertigfunktionen möglich ist.

Wenn der Socket nicht klappt, brauch ich gar nicht erst einen Leseversuch vorzunemehmen.

Dachtest du, der http-Wrapper in file_get_contents() ist so dämlich, ohne Fehlerbehandlung zu arbeiten und bricht nicht ab, wenn schon der Verbindungsaufbau nicht klappte?

Wenn aber ein Socket eröffnet werden kann, und ich dann nicht lesen kann, kann ich bei der handle-basierten Vorgehensweise den Stream-Kontext abfragen. Und der sagt mir dann, warum die Ressource nicht lesbar war.

Der kann auch nicht hinter die Kulissen schauen. Das einzige Ergebnis ist der Response-Header - und der ist auch mit den Fertig-Funktionen abfragbar. Na gut, dass der Timeout zugeschlagen hat, kann man auch noch erkennen. Das kann man zur Not noch mit Zeitdifferenzmessen bei den Fertigfunktionen ermitteln, wenn man (warum auch immer in solch einem Fall) den Stream-Kontext-Parameter nicht versorgt hat. Aber warum der Timepout kam, steht auch nicht in dem Stream-Kontext.

Diese Möglichkeit stellt mir die "Schwarze-Kisten-Funktion" trotz ihrer irrwitzigen vielen Schalter und "local source populated arrays" nicht zur Verfügung. Aber vielleicht bauen die das ja auch noch ein? Dann wäre der Unsinn komplett.

Der Stream-Kontext ist schon eingebaut. Die einzige Möglichkeit der Auswertung, die ein Client hat, ist die Auswertung der Response-Header und vielleicht noch der vergangenen Zeit. Die Response-Header bekommt man mit den "Handle-Funktionen" ob man will oder nicht als Teil des Response-Stroms. Wenn man eine Funktion mit dem Wrapper für http verwendet, hat man sie getrennt von den Nutzdaten in $http_response_header stehen.

Lo!

[dedlfix]

Hi!

Soweit ich das bisher festellen konnte, halten sie bei den Streams innerhalb der namensbasierten Funktionen noch nicht einmla die Forderung nach POSIX ein, dass der Stream während der Bearbeitung gesperrt sein muss.
Und was genau bringt das im vorliegenden Falle einer abzufragenden HTTP-Ressource?
Du bist aber neugierig :-)
Und außerdem vergesslich! Das haben wir beide nämlich neulich erst diskutiert.
https://forum.selfhtml.org/?t=206470&m=1401770

Nein, hatten wir nicht. Du hast da nur was erzählt und ich es nicht weiter kommentiert. Zudem ging es dabei darum, dass ein Webserver etwas nicht ausliefern kann, weil der grad ein internes Problem hat. Ob das eine Sperre ist oder was anderes ist für einen Client nicht erkennbar. Eine Sperre, bei der ein Webserver eine Ressource nicht lesen kann, dürfte zudem sehr selten vorkommen. Dateien und Scripte liegen üblicherweise rum und müssen nur gelesen werden. Dass sie wegen einer Aktualisierung gerade gesperrt sind, ist zwar möglich aber eher sehr gering wahrscheinlich. Anderenfalls hat der Programmierer Mist gebaut und viele Clients würden sich wegen Nicht-200er-Antworten beklagen müssen.

Aber sei's drum. Im vorliegenden Fall forderst du jedoch, dass die Möglichkeit, Sperren einzulegen auch für HTTP-Ressourcen-Abfragen zur Verfügung stehen müsse. Zumindest war das grad das Thema, als du mit dem Argument kamst, dass die für Abfragen verwendeten Funktionen nicht alle eine Sperrmöglichkeit haben.

Wenn grad ein Prozess einen HTTP-Request durchführt, dann kann ein weiterer HTTP-Request sehr gut parallel durchgeführt werden. Darauf sind sowohl der lokale TCP/IP-Stack als auch der zu befragende Webserver ausgelegt. Zudem gibt es keinen standardisierten Mechanismus, dass ein Client einem Server eine Sperre einlegen kann. (Sonst müsste man DoS-Angriffe auch nicht üblicherweise mit einer ganzen Armee an Clients starten - eine kleine Sperre tät reichen.)

Man kann anders nicht feststellen, WARUM die Ressource ggf. nicht erreichbar ist. Sie könnte nämlich temporär gesperrt sein. Dann funktioniert fsockopen() zwar noch fehlerfrei, man kann aber den Socket nicht lesen.

Ja und? Wenn der Vorgang nicht geklappt hat und ich ihn wiederholen will, kann ich auch file_get_contents() nochmal starten, ohne den im Hintergrund ablaufenden Vorgang in Einzelschritten selbst nachzugestalten.

Bei Verwendung der namensbasierten Version (file_get_contents()) bekommt man nur ein false. Das kann dann bedeuten, dass die Ressource nicht existiert, dass sie momentan gesperrt ist oder sonstige Fehler beim Lesen aufgetreten sind.

Wenn es reicht, ist das doch ok. Der Aufwand, da ins Details zu gehen und die Anwendung für jede mögliche Fehlerbedingung einzeln reagieren zu lassen, sollte gut überlegt sein. Bei einer nicht abfragbaren Ressource kann man sowieso nicht viel mehr tun, als den Vorgang zu wiederholen oder ihn abzubrechen.

Wenn sie aber nur gesperrt wäre, würde sich ein späteres Nachfragen nochmal lohnen.

Dann nochmal die Frage aus dem anderen Posting: Wie ist der HTTP-Status-Code für "Ressource ist gesperrt"? Open klappt noch, Read nicht mehr, kann auch bei einer in dem Moment ausgefallenen Netzwerkverbindung auftreten. Ob da eine Sperre aktiv ist, oder eine andere temporäre Unpässlichkeit, ist für mich als Client nicht herausfindbar, nicht änderbar und demzufolge nicht weiter interessant. Abbruch oder Wiederholung stehen nur als Reaktion zur Verfügung. Aber wie gesagt, wir kommen vom Thema ab, das nicht Erkennen von Sperren sondern Anwenden von Sperren bei HTTP-Requests war (oder ich habe deine Forderung missgedeutet).

Lo!

[Tom]

Hello,

Aber sei's drum. Im vorliegenden Fall forderst du jedoch, dass die Möglichkeit, Sperren einzulegen auch für HTTP-Ressourcen-Abfragen zur Verfügung stehen müsse. Zumindest war das grad das Thema, als du mit dem Argument kamst, dass die für Abfragen verwendeten Funktionen nicht alle eine Sperrmöglichkeit haben.

Ich habe _hier_ nicht die fehlende Sperrmöglichkeit bemängelt, sondern die fehlende Möglichkeit, Statusabragen getrennt für jede Schicht (Socket, Lessezugriff) zu erhalten, bzw. auf vorhandene Sperren intelligent zu reagieren.

An den Stream-Kontext kommt man aber mWn nur bei den handlebasierten Funktionen heran. Und die $http_response_headers stehen auch nicht immer zur Verfügung.

Das lässt sich aber bestimmt auch noch herausbekommen, warum die beim zweiten Zugriff auf die gesperrte Ressource bis in alle Ewigkeit auf sich warten lassen, obwohl sie beim ersten noch nach dem HTTP-Timeout geliefert werden.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg