nicht angemeldet
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!