[PHP] Endlos-Umleitungsschleife, wieso?

[Matze]

Hallo,

ich habe eine Datei (index.php) die ganz grob so aussieht:

Code:

<?php

function parse()
{
  // ...
}

if (parse())
{
   header('Location: index.php');
   exit;
}

?>

Die Funktion parse() parst Dateien, die in einem Verzeichnis liegen. Wenn eine Datei erfolgreich geparst wurde, wird der geparste Inhalt gespeichert. Dann wird die index.php erneut aufgerufen.
Beim Versuch, die gleiche Datei erneut zu parsen, wird geprüft, ob diese bereits existiert. Ist das der Fall, gibt die Funktion parse() "false" zurück und die nächste Datei im Verzeichnis wird geparst. Das geht theoretisch so lange, bis alle Dateien geparst sind.
Leider nur theoretisch. Nach rund 10-15 Dateien meldet Firefox einen Umleitungsfehler: "Die aufgerufene Website leitet die Anfrage so um, dass sie nie beendet werden kann."
Drücke ich F5, dann läuft das Skript einwandfrei weiter und parst die nächsten 10-15 Dateien bis zum nächsten Umleitungsfehler.

Wieso kommt es denn zu einer (Endlos-)Umleitungsschleife oder was mit FF damit sagen möchte?

Edit: Es handelt sich übrigens um eine Klasse und da rufe ich das innerhalb einer Methode auf. Es ist natürlich unschön, eine Klasse bzw. Methode so zu verlassen, aber das sollte erstmal keine Rolle spielen und das werde ich auch noch ändern.

Grüße, Matze

[Dax]

Nach einer gewissen Zahl Redirects auf _immer die selbe Seite_ vermutet der FF, dass das auf Ewig so weitergeht. Häng' einfach einen Parameter, vielleicht nen Integer, dran, und das sollte sich ändern

[himitsu]

*nochmals überleg*

Das header('Location: index.php'); weißt ja den Browser an eine andere Seite zu laden, statt diese hier. (HTTP/1.0 303 ?)

ich würd mal denken, daß FireFox eine maximale Rekursionstiefe eingebaut hat, damit es nicht endlos läd.


war das eigendlich dein eigener Server?

ich kann bei meinem Space das Timeout abschalten und auch den Abbruch seitens Browser irgnorieren lassen ... könnte also EIN Script "ewig" laufen lassen und dann alle Dateien auf einmal verarbeiten.


[add]
Tipp: wenn du das Timeout bei dir auch abschalten/hochsetzen kannst

schicke nach jeder Datei eine (Status)Zeile an den Browser (incl flush buffer, damit es auch sofort verschikt wird) und verarbeite soviele Dateien, bis der Browser die verbindung trennt ... soviel wie möglich in einer Datei

nach 'ner gewissen Zeit könnte man ja per Meta-Tag oder Java-Script dem Browser einen Reload-Befehl schicken, wo er dann die Datei erneut läd und beendet dabei gleich die aktuelle Datei (die Neue wird ja vermutlich gleich gestartet) ... somit würde man das Script nicht ewig laufen lassen.

[Matze]

Hi ihr zwei!

@Dax: Das hat leider nichts zum Erfolg geführt.
@himi: Mir ist bewusst, dass ich das PHP-Timeout höher setzen kann. Ob es der Server zulässt habe ich nicht getestet. Aber das einfach auf 10 Minuten zu setzen und hoffen, dass alle Dateien in der Zeit durchlaufen werden, gefällt mir nicht.
Und nein, es ist kein eigener Server im Sinne von "mir gehört die Hardware". Ich habe halt so ein Web-Paket im Internet (Webspace etc.).

Das ganze möchte ich nachher per Cronjob vielleicht 1 x pro Woche/Tag ausführen. Wenn diese Umleitungsschleife vom Browser irrtümlich angenommen wird, dürfte ich das Problem beim Cronjob eigentlich nicht haben.
Daher geht die Meta-Tag-Lösung auch nicht. Vielleicht ist es wirklich nur der Browser, der mich veräppeln möchte und alle geht wie es soll.

Wobei es natürlich schön wäre, wenn das auch über den Browser funktionieren würde.

Grüße, Matze

[Dax]

Ein Cronjob folgt aber, glaube ich, doch gar keinen redirects?
Und probier doch mal wget statt Browser, oder ein kleines Indy-Programm, das nix weiter tut als Redirs zu folgen

[Matze]

Hm meinem Cronjob gebe ich an, dass eine PHP-Datei ausgeführt wird. Und eine header()-Weiterleitung wird meines Wissens nicht vom Browser ausgeführt, dafür geht die viel zu schnell.

Wenn ich wüsste, was ein Cronjob so alles macht.
Einen Tag mal ein winziges digitales Männlein zu sein, das in den Serverprogrammen schaut, wie das so funktioniert, wäre was ...

[himitsu]

 Und eine header()-Weiterleitung wird meines Wissens nicht vom Browser ausgeführt, dafür geht die viel zu schnell. doch doch ... Herader wird an den Browser geschickt und der wertet es aus

[Matze]

Achso hm, dann ist der aber sehr fix. Dann geht das mit header() ja gar nicht so, wie ich es mir vorgestellt hatte.

[Dax]

Nimm einfach wget, das gibts für Windows und ist bei Linux fast immer dabei

Code:

wget --max-redirect=999999 [url]www.dein.name/pfad[/url] -O /dev/null

[mquadrat]

Für das aktuelle Problem zwar nicht geeignet, aber vielleicht liest das ja auch mal jemand, der das Problem außerhalb von Cron-Job hat: Müsste man mittels AJAX lösen können. Die Hauptseite macht immer einen AJAX Call auf die parse-Routine und die meldet einen Status zurück. Je nach Status dann nochmal aufrufen oder den Aufruf beenden.

Bei nem Cronjob wird das ja sicherlich nicht funktionieren. Da könnte man höchstens etwas "optimieren" und sagen wir mal jeweils 5 Dateien parsen vor dem Redirect. Das würde die Wahrscheinlichkeit in den Timeout zu rennen erhöhen, aber dafür die Anzahl der nötigen Redirects fünfteln.