Hi there,
Keine Ahnung warum, aber wenn die Anwendung in einem domainfremden Iframe läuft, dann reagiert PHP viel pikierter auf Errors und dadurch diese Lade- und sonstigen Fehler.
Das ist jetzt deine Beobachtung, aber gestatte bitte trotzdem, dass ich da Zweifel habe.
Ich glaub's ja selbst nicht. Wahrscheinlich war's auch nicht so. Ich denke, ich hab das nur scheinbar "repariert", in dem ich einem nicht bekannten $_SESSION-Index einen default-Wert gegeben habe (der dann eine PHP-Datei includen kann, deren Name vom Wert dieser Variablen abhängt; oder, um es weniger kryptisch zu machen, wenn zB $_SESSION['lang'] den Wert 'de' hat, dann ladet das Skript die Datei "../languages/lang_de.inc.php".
Das eigentliche Problem aber ist, daß dieser Wert eigentlich nie leer sein darf; daß er es trotzdem ist, ist die eigentlich Folge des cors-Problems, das damit noch immer nicht gelöst wurde (ich weiß wie das zu lösen ist, aber das Problem ist, daß in dem Fall beide Server (also der Hauptseite und dem, was im Iframe läuft) nicht unter meiner Verwaltung stehen und der Entwickler der Rahmenseite gemeint hat, er hätte die Geschichte mit dem Iframe und dem Session-Cookie auf seine Weise gelöst (was er aber offenbar nicht hat)
Die konkrete Ursache muss anders geartet sein. Der Server weiß nur sehr begrenzt etwas davon, ob der Request aus einem nackigen Browserfenster, einem iframe, einem frame, einem Ajax-Request oder einen wget-Aufruf kommt.
Du hast ja soo recht, aber immerhin, über Deine Überlegungen bin ich auf die eigentliche Ursache gekommen, auch wenn mir jetzt bewußt ist, daß die Baustelle ein viel größere ist und meine "Lösung" so sinnvoll und wirksam ist wie eine Decapitation bei Kopfschmerzen...