Seite hört nie auf zu laden. Debugger?

[Jörg Roßdeutscher]

Hallo,

ich habe folgendes Problem: Eine Site, die auf zwei meiner Entwicklungsserver (Linux/Apache) prima läuft, hat auf dem finalen Gerät ein Problem: Obwohl sie ansonsten prima rennt, hört sie nie auf zu laden. Das betrifft Firefox(Mac) und Internet Explorer 6(Windows). Der IE sagt endlos, es würde noch ein Objekt geladen, beim Firefox hört die Cursoranimation nie auf. Nie heisst: Selbst nach einer halben Stunde… Kein Problem unter Opera und Safari.

Deswegen wird der onload-Event nie ausgelöst - und das ist ein Problem.

Ich will mir das jetzt nicht vorkauen lassen. Das ganze verschwindet, wenn ich den FCKeditor deaktiviere, die Serverlogs besagen nix besonderes, die Firefox-Konsole auch nicht. Die Site ist dynamisch und viel zu komplex, um hier einen Schnipsel zu posten.

Was mich eigentlich interessiert ist:

Wie kann ich herausfinden, welcher Codeschnipsel hier endlosrunden dreht? Anscheinend werden alle Elemante geladen, also vermute ich eine Javascript-Schleife oder sowas. Gibt es einen Debugger, der mir anzeigt, was noch "läuft" oder fehlt oder so?

Und wieso verhält sich ein Server anders als der andere? Welche Apache/PHP-Einstellungen könnten sowas beeinflussen, mir fällt nichts ein?

Bin root auf allen Kisten.

Danke,
Gruß,
Jörg

[Der Martin]

Hallo Jörg,

ich habe folgendes Problem: Eine Site, die auf zwei meiner Entwicklungsserver (Linux/Apache) prima läuft, hat auf dem finalen Gerät ein Problem: Obwohl sie ansonsten prima rennt, hört sie nie auf zu laden.

spontan und ohne weitere Detailinfo würde ich jetzt mal vermuten, der Server sendet einen Content-Length-Header mit einer falschen (zu großen) Angabe. Der Client erwartt also z.B. 6376 Bytes, der Server schickt aber nur 6334, der Client wartet dann "brav" auf das letzte Paket, das nie mehr kommt.

Das betrifft Firefox(Mac)

Nicht FF/Win oder FF/Linux?  Ich hätte erwartet, dass sich eine Browser-Familie wenigstens konsistent verhält. Naja, aber vielleicht erkennt der eine oder andere Browser das Ende der Ressource auch daran, dass die TCP-Verbindung beendet wird. Der IE merkt sowas zum Beispiel nicht, der läuft höchstens irgendwann in seinen eigenen Timeout - und auch das nicht garantiert ...

Ich will mir das jetzt nicht vorkauen lassen. Das ganze verschwindet, wenn ich den FCKeditor deaktiviere, die Serverlogs besagen nix besonderes, die Firefox-Konsole auch nicht. Die Site ist dynamisch und viel zu komplex, um hier einen Schnipsel zu posten.

Ich würde tatsächlich mal die HTTP-Header, vor allem Content-Length ansehen und mit der tatsächlich übertragenen Datenmenge vergleichen.

So long,
 Martin

[Jörg Roßdeutscher]

Hallo Martin,

Danke schon mal für deine Antwort.

ich habe folgendes Problem: Eine Site, die auf zwei meiner Entwicklungsserver (Linux/Apache) prima läuft, hat auf dem finalen Gerät ein Problem: Obwohl sie ansonsten prima rennt, hört sie nie auf zu laden.

spontan und ohne weitere Detailinfo würde ich jetzt mal vermuten, der Server sendet einen Content-Length-Header mit einer falschen (zu großen) Angabe. Der Client erwartt also z.B. 6376 Bytes, der Server schickt aber nur 6334, der Client wartet dann "brav" auf das letzte Paket, das nie mehr kommt.

Ich wusste gar nicht, dass dieses Problem auftreten kann. Das klingt sehr plausibel.

Das betrifft Firefox(Mac)

Nicht FF/Win oder FF/Linux?

Ich habe hier einen Mac, alles andere läuft nur emuliert in Parallels, deswegen waren meine Angaben nur Stichproben. Ich nehme an, das z.B. FF konsistent reagiert.

Da es sich um das Admin-Interface unseres CMS handelt, brauchen auch nur „zertifizierte“ Browser laufen. Und zertifizieren tu ich  ;-)

Ich würde tatsächlich mal die HTTP-Header, vor allem Content-Length ansehen und mit der tatsächlich übertragenen Datenmenge vergleichen.

Das wird schwierig. Das Problem tritt mit dem FCKeditor auf, der u.a. iframes dynamisch generiert und wahnsinnig viel Zeugs nachlädt. Da ist kaum ein Überblick zu bekommen.

Ich würde das Problem gern anders herum angehen. Wüsstest Du eine Möglichkeit, warum das Problem auftritt?
Oder kennst Du eine Methode, wie man das Problem übersichtlich provozieren kann?

Spontan und aus dem Bauch heraus fällt mir bei Datenlänge nur mod_gzip ein, wer sonst spielt denn an sowas herum?

Da das ganze auf meinen Linux-Kisten prima läuft und der Kunden-Webserver (BSD) einen eher unguten Eindruck hinterlässt (Schnellschusseinrichtung…), würe ich aus dem Bauch heraus ein Serverproblem vermuten. Leider bin ich in BSD auch nicht so firm wie in Linux.

Gruß,
Jörg

[Der Martin]

Hallo Jörg,

Das betrifft Firefox(Mac)
Nicht FF/Win oder FF/Linux?
Ich habe hier einen Mac, alles andere läuft nur emuliert in Parallels, deswegen waren meine Angaben nur Stichproben. Ich nehme an, das z.B. FF konsistent reagiert.

ach so, ich hatte angesichts deiner Formulierung gedacht, es betrifft *nur* FF/Mac.

Da es sich um das Admin-Interface unseres CMS handelt, brauchen auch nur „zertifizierte“ Browser laufen. Und zertifizieren tu ich  ;-)

Hehe. :-)
"§1. Ich bin der Boss."

Ich würde tatsächlich mal die HTTP-Header, vor allem Content-Length ansehen und mit der tatsächlich übertragenen Datenmenge vergleichen.
Das wird schwierig. Das Problem tritt mit dem FCKeditor auf, der u.a. iframes dynamisch generiert und wahnsinnig viel Zeugs nachlädt. Da ist kaum ein Überblick zu bekommen.

Clientseitig meine ich natürlich. Unter Windows oder Linux würde ich Wireshark (ehemals Ethereal) drauf loslassen; ob es auf Mac OS etwas Entsprechendes gibt, weiß ich natürlich nicht. Aber irgendein HTTP-Sniffer müsste doch da auch existieren, notfalls ein protokollierender transparenter Proxy.

Ich würde das Problem gern anders herum angehen. Wüsstest Du eine Möglichkeit, warum das Problem auftritt?

Warum?? Nee, da bin ich überfragt, kann ich nur mutmaßen. Etwa ein Script, das so einen Header generiert, aber bei der Berechnung des Datenvolumens nicht alle Beiträge berücksichtigt.

Oder kennst Du eine Methode, wie man das Problem übersichtlich provozieren kann?

<?php  
header("Content-Type: text/plain");  
header("Content-Length: 400");  
echo "Nur ein kurzer Text, viel weniger als 400 Bytes."  
?>

Aber bei der weiteren Fehlersuche müsste ich mich auch in Mutmaßungen verstricken ...

So long,
 Martin

[Jörg Roßdeutscher]

Hallo,

Ich würde tatsächlich mal die HTTP-Header, vor allem Content-Length ansehen und mit der tatsächlich übertragenen Datenmenge vergleichen.
Das wird schwierig. Das Problem tritt mit dem FCKeditor auf, der u.a. iframes dynamisch generiert und wahnsinnig viel Zeugs nachlädt. Da ist kaum ein Überblick zu bekommen.

Clientseitig meine ich natürlich. Unter Windows oder Linux würde ich Wireshark (ehemals Ethereal) drauf loslassen; ob es auf Mac OS etwas Entsprechendes gibt, weiß ich natürlich nicht. Aber irgendein HTTP-Sniffer müsste doch da auch existieren, notfalls ein protokollierender transparenter Proxy.

Klar, ich kann ethereal auf meinem Router per X11 auf meinen Bildschirm holen.
Aber FCKeditor ist ein kompletter grafischer Editor im Browser. Dazu kommt mein nicht gerade kleines CMS-Admin-Interface, da ist allein der generierte HTML-Code über 100 Kb groß.

Fazit: Ich habe mehrere hundert Anfragen für einen ungecachten Aufruf. Da suche ich mich dumm und hässlich nach der einen Datei, die irgendwie falsch ist. iFrames generieren ja wieder eigene „Seiten“.

Dazu kommt, dass ich bei den php-generierten Inhalten ja gar nicht weiss, wie lang der Content sein muss. Bei dem vom FCKeditor erst recht nicht. Und weil wir Inhalte vor der Ausgabe parsen, haben wir sogar einen eigenen Ausgabepuffer…
Dazu kommt anscheinend, gestern bemerkt, dass es anscheinend manchmal doch fehlerfrei funktioniert, wenn der Aufruf nicht einfach per Link kam, sondern nach einem Formularabschicken passiert…

Ich seh´s mal so: Wenn Du mich mit dem Code für 30 Jahre in die gleiche Kerkerzelle steckst, komme ich vielleicht drauf. 8-) Derzeit bin ich wohl eher drauf angewiesen, dass jemand das Problem bei einer kleineren Implementation gefunden hat und „kennt“.

Warum?? Nee, da bin ich überfragt, kann ich nur mutmaßen. Etwa ein Script, das so einen Header generiert, aber bei der Berechnung des Datenvolumens nicht alle Beiträge berücksichtigt.

Negativ… ausser ein paar Content-Type Geschichten keine Header…

Oder kennst Du eine Methode, wie man das Problem übersichtlich provozieren kann?

<?php

header("Content-Type: text/plain");
header("Content-Length: 400");
echo "Nur ein kurzer Text, viel weniger als 400 Bytes."
?>

  
Grunz. Darauf hätte ich auch selbst… (Ärger). Danke. WIe dem auch sei: Das läuft problemlos durch.  
  

> Aber bei der weiteren Fehlersuche müsste ich mich auch in Mutmaßungen verstricken ...  
  
Wenn Du noch welche hast - besser Mutmassungen als nix. Ich werde mir wohl noch mal die Apache-Config durchsehen, und die php.ini. Beides ist nicht von mir und auch nicht meine Kernkompetenz, aber vielleicht finde ich was… Vielen Dank Dir für deine Mühe.  
  
Gruß aus Hamburg,  
Jörg