Ankündigung

Einklappen
Keine Ankündigung bisher.

file_get_contents erzeugt timeout

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • file_get_contents erzeugt timeout

    Hallo liebe Community,

    ich rufe meine Datenschutzerklärung vom Server eines Anwalts ab. Das ging einige Zeit recht gut. Seit ein paar Wochen führt der Abruf jedoch zu einem Timeout. Ich habe mittlerweile dem Programmierer der Seite geschrieben, der meinte ich solle den timeout meiner Anfrage hochsetzen. Das hat allerdings auch keine Änderung gebracht. Das Seltsame ist das eigenwillige Auftreten des Fehlers:

    Auf meiner Webseite tritt der timeout praktisch immer auf. Diese Seite habe ich als Entwicklervariante auch noch bei einem anderen Hoster in einem Unterverzeichnis (1:1-Kopie) liegen. In dieser DEV-Version funktioniert der Abruf einwandfrei. Also dachte ich, es läge an meinem Hoster.
    Nun habe ich gerade eine Kundenseite fertiggestellt, die bei dem "funktionierenden" Hoster läuft. Hier tritt das gleiche Phänomen auf: Die aktive Seite zickt, aber die DEV-Seite läuft sauber.
    Als Test habe ich nun auf meinem Server ein Unterverzeichnis "test" erstellt und in diesen den Ordner "Datenschutz" kopiert, also für die gleiche Struktur wie bei der DEV-Seite gesorgt. Fehler tritt auch hier auf. Auch hier bekomme ich die Fehlermeldung:
    failed to open stream: Connection timed out
    Nun hatte ich die .htaccess-Datei im Verdacht und habe diese vorübergehend außer Betrieb genommen. Doch auch diese Aktion brachte keinen Erfolg.

    Hier der code, des Abrufs:

    Code:
    $page = file_get_contents('https://erdse.net/LNGU8401B3606ITTG8VHTVJRC/de/koenigs.one.html', false, stream_context_create(array('http'=>array('timeout' => 20))));
    Es funktioniert übrigens auch nicht ohne den Anhang mit dem stream_context_create

    Ich bin mittlerweile völlig ratlos, wie ich dieses Timeout-Problem lösen kann. Hat jemand eine Idee, woran es liegen könnte?


  • #2
    Ein Connection Timeout ist ein Netzwerkproblem und sollte mit dem Netzwerkadministrator besprochen werden. Mit PHP hat das nicht wirklich was zu tun.

    Kommentar


    • #3
      So dachte ich anfangs auch, deshalb informierte ich gleichden Support meines Anwalts.

      Was aber gegen ein Netzwerproblem (bei der Quelle) spricht, ist die Tatsache, dass die DSE von anderen Servern abgerufen werden kann. Ich habe deshalb auch schon eine Anfrage an meinen (nicht funktionierenden) Hoster gestellt. Dort wurde aber kein Fehler am Server festegestellt, sondern auf einen möglichen Fehler im php-Skript verwiesen.

      Kommentar


      • #4
        Tja, da hat man dir ein Blödsinn erzählt. Wenn die URL wirklich korrekt und ein Tippfehler ausgeschlossen ist, ist es klar ein Netzwerkproblem.

        Kommentar


        • #5
          Stellt sich aber dann folgende Frage: Meine Seite macht Ärger bei Hoster 1.
          Die Seite meines Kunden macht Ärger bei Hoster 2.
          Meine DEV-Seite und die DEV-Seite meiner Kundin funktionieren aber beide bei Hoster 2.
          Also kann doch zumindest Hoster 2 kein Problem haben. Oder kann es an einer fehlerhaften Konfiguration im jeweiligen Server liegen? Nur was wäre dann dort der Fehler?

          Kommentar


          • #6
            Vielleicht musst du einen Proxy bei Hoster 1 verwenden
            Eine Mannschaft aus Granit! So wie einst Real Madrid!
            Und so zogen wir in die Bundesliga ein und wir werden wieder Deutscher Meister sein!

            Kommentar


            • #7
              Die Einstellungen für "default_socket_timeout" in der "php.ini" könnten für das unterschiedliche Verhalten verantwortlich sein.

              Kommentar


              • #8
                Möglicherweise wäre es außerdem schlicht klüger, die Datenschutzerklärung nur einmal am Tag herunterzuladen und dann lokal bereit zu halten...

                etwas wie

                Code:
                cd /wohin/auch/immer; wget -O dse.html https://erdse.net/LNGU8401B3606ITTG8VHTVJRC/de/koenigs.one.html
                in einer Crontab wirkt Wunder.

                Kommentar


                • #9
                  Zitat von KnigMarkus Beitrag anzeigen
                  (...)
                  failed to open stream: Connection timed out
                  (...)
                  Code:
                  $page = file_get_contents('https://erdse.net/LNGU8401B3606ITTG8VHTVJRC/de/koenigs.one.html', false, stream_context_create(array('http'=>array('timeout' => 20))));
                  Es funktioniert übrigens auch nicht ohne den Anhang mit dem stream_context_create

                  Ich bin mittlerweile völlig ratlos, wie ich dieses Timeout-Problem lösen kann. Hat jemand eine Idee, woran es liegen könnte?
                  Mit dem Stream-Context-Parameter 'timeout' kannst du nur den Timeout für die Lesezugriffe nach erfolgreicher Verbindungsaufnahme einstellen. Deine Fehlermeldung bezieht sich aber auf den Timeout bei der Verbindungserstellung. Ob man den mit file_get_contents() überhaupt ändern kann, entzieht sich meiner Kenntnis.

                  Wenn du die Datenabfrage "von Hand" nachbaust, kannst du stream_socket_client() ein entsprechendes Argument mitgeben.

                  Wenn man die Wurst schräg anschneidet, hält sie länger, weil die Scheiben größer sind.

                  Kommentar


                  • #10
                    Vielen Dank schon mal für die Vorschläge.

                    socket_timeout steht auf 60, was wohl ein normaler Wert ist.
                    Cronjob muss ich am Montag testen, wenn mein Hoster wieder normal erreichbar ist.
                    Der Versuch mit stream_socket_client erzeugt leider einen Fehler, mit Hinweis auf Konfigurationsfehler in PHP. Das ist wohl auch was für den Hoster-Support.

                    Kommentar


                    • #11
                      Man könnte "curl" anstelle von "file_get_contents" verwenden. Vgl. etwa

                      https://github.com/matomo-org/tracker-proxy/issues/16

                      Kommentar


                      • #12
                        Danke, aber mit Curl hatte ich es auch schon versucht. Das Problem scheint wohl doch im Bereich meines Servers zu liegen.

                        Da werde ich morgen mal dem Support auf die Nerven gehen müssen.

                        Kommentar


                        • #13
                          Oder Guzzle:

                          http://docs.guzzlephp.org/en/stable/

                          Kommentar


                          • #14
                            Das Problem ist scheinbar gelöst. Mein freundlicher Support hat mich auf den Parameter
                            Code:
                            allow_url_fopen
                            hingewiesen. Dieser stand in der nicht funktionierenden Seite auf off. Seit ich ihn auf on änderte, funktioniert die Seite problemlos.

                            Kommentar

                            Lädt...
                            X