Perl-Script per command line geht - über Apache bricht es ab

[Christian Schnagl]

Hallo Perl/Apache Profis!

Habe eine Datei "testfile.html".
Diese sieht so aus:

1<br>
2<br>
3<br>
...
500000<br>

Wenn ich diese Datei über Apache ausliefere, funktioniert alles

Wenn ich diese Datei mittels Perl-Script + Apache ausliefere, bricht der Browser nach ca. 5000-6000 Zeilen ab (immer an anderer Stelle).
Hier mein Script:

#!/usr/bin/perl
print "Content-type: text/html\n\n";

open(FILE,"testfile.html");
while (<FILE>) { print ; }
close(FILE);

Es äußert sich so, daß er immer ein paar tausend Zeilen lädt und dann von vorne beginnt. Das macht er ein paar mal und danach bleibt der Browser einfach stehen bei einer Zahl um 5000.

Wenn ich das Script auf Kommandozeilen-Ebene aufrufe, funktioniert es einwandfrei.

Mein Betriebssystem: Windows XP Pro

Habe es schon auf 3 verschiedenen PCs probiert. Habe auch Win XP Pro neu installiert, danach Apache und dann Perl. Sonst keine andere Software. Selbst dann geht es nicht.

Habe es mit Apache 1.3 und 2.0 probiert. Habe es auch probiert mit einer xampp-Lösung.

Unter Unix / Linux funktioniert alles einwandfrei.

Hat jemand eine Idee, warum es unter XP nicht geht?

Danke für jede Hilfe !

Christian Schnagl

PS: Es schein kein TIME-OUT Problem zu sein, da der Fehler bereits nach 1-2 Sekunden auftritt.

PPS: Michael Schröpl hatte das gleiche Problem in 1999: http://forum.de.selfhtml.org/archiv/1999_3/t04823.htm
Leider führt dieser Archiveintrag zu keiner Lösung.

[Philipp Hasenfratz]

Halihallo Christian

Wenn ich diese Datei mittels Perl-Script + Apache ausliefere, bricht der Browser nach ca. 5000-6000 Zeilen ab (immer an anderer Stelle).

Ja, das Problem kenne ich nur zu gut, leider. Und verflixt, ich bin schon zwei Monate
auf der Suche nach einer Lösung[1] und habe bisher nichts gefunden. Nun, ich habe
festgestellt, dass das Problem bei mir nur auf dem IE zu reproduzieren ist, alle anderen
funktionieren und zweitens, dass der IE mit "kurzen Zeilen" weniger Probleme hat; sprich
nach anfügen von newlines bei der Ausgabe kam er weiter (aber bis zum Ende leider auch
nicht immer).

open(FILE,"testfile.html");
while (<FILE>) { print ; }
close(FILE);

Tja, du gibst hier auch die Newlines aus... Das ist schon mal gut.

Es äußert sich so, daß er immer ein paar tausend Zeilen lädt und dann von vorne beginnt. Das macht er ein paar mal und danach bleibt der Browser einfach stehen bei einer Zahl um 5000.

Ja, bei mir ist die Zahl jedoch höchst variabel. Manchmal lädt er ca. 500 bytes, manchmal
20000 bytes.
Ich habe es über einen HTTP-tracer getestet und festgestellt, dass der _Browser_
(folglich führe ich das Problem nicht auf den Apachen zurück, den ich auch verwende)
die Requests startet.

Wenn ich das Script auf Kommandozeilen-Ebene aufrufe, funktioniert es einwandfrei.

dito.

Unter Unix / Linux funktioniert alles einwandfrei.

Nun, als Client habe ich es nicht getestet, aber Linux als Serverbetriebssystem mit
Apachen löste bei mir das Problem nicht. Ich vermute die Problematik wirklich beim
Client, sprich: IE? für Windows.

---

Tja, ich schätze mal, wir sitzen im selben Boot, ich wünschte nur, dass es unter anderen
Umständen wäre :-)

Viele Grüsse

Philipp

[Andreas Korthaus]

Hi!

Tja, ich schätze mal, wir sitzen im selben Boot, ich wünschte nur, dass es unter anderen
Umständen wäre :-)

Hast Du mal probiert die Daten gzip-komprimiert auszugeben? Das bewirkt bei mir manchmal wahre Wunder ;-)

Grüße
Andreas

[Philipp Hasenfratz]

Halihallo Andreas

Huch, mein Posting wurde vom Forums-Daemonen geschluckt... Nun denn, so leicht gebe
ich mich nicht geschlagen!

Tja, ich schätze mal, wir sitzen im selben Boot, ich wünschte nur, dass es unter anderen
Umständen wäre :-)
Hast Du mal probiert die Daten gzip-komprimiert auszugeben? Das bewirkt bei mir manchmal wahre Wunder ;-)

Öhhh, nein, zumindest nicht für dieses Problem. Aaaaaber: Wenn die Ausgabedaten korrupt
sind, dann stimmt die Checksum (falls eine gebildet ist, was bei Deflate IMHO nicht so
ist) nicht mehr, bzw. die Dekompression schlegt fehl oder gibt noch mehr Blödsinn aus.
Mag sein, dass man dann einfach etwas mehr Zeilen ausgeben lassen kann, aber das
entspricht lediglich der Bekämpfung einiger Symptome, lösen jedoch das Problem nicht.

Nichts desto trotz: Ratsam ist die Kompression natürlich (fast?) immer :-)

BTW: Zu dem Thread, dessen Überschrift du geändert hast: einer ist darauf aufmerksam
geworden :-)  hatte aber nix anzufügen, da du schon alles wesentliche gesagt hast. Und
ich hätte doch so gerne mitdiskutiert (spannendes Thema) :-((
Nun, aber den Nick "int21h" fand ich wirklich toll, hat mich wieder an die gute alte
Zeit erinnert (INT 21h ist der Systeminterrupt vom DOS-OS).

Viele Grüsse

Philipp

[Andreas Korthaus]

Hi Philipp!

Huch, mein Posting wurde vom Forums-Daemonen geschluckt... Nun denn, so leicht gebe
ich mich nicht geschlagen!

recht so ;-)

Hast Du mal probiert die Daten gzip-komprimiert auszugeben? Das bewirkt bei mir manchmal wahre Wunder ;-)

Öhhh, nein, zumindest nicht für dieses Problem. Aaaaaber: Wenn die Ausgabedaten korrupt
sind, dann stimmt die Checksum (falls eine gebildet ist, was bei Deflate IMHO nicht so
ist) nicht mehr, bzw. die Dekompression schlegt fehl oder gibt noch mehr Blödsinn aus.

Naja, ich hatte mal ein etwas ähnliches problem als ich das Synchonisations-Script zw. einem Windows und einem Unix-Server geschrieben habe(vielleicht erinnerst Du Dích ja noch ;-)), da hatte ich zwischendurch ganz komische Probleme, was glaueb ich an irgendwelchen Fehlinterpretierten Zeilenumbrüchen lag(oder sowas in die Richtung, so ganz genau habe ich das nicht feststellen können). Naja, als ich das ganez dann komprimiert übertragen habe waren e dann halt binäre Daten, und ab da gab es keine Probleme mehr. Ich dachte vielleicht könnte das auch hier helfen...

Nichts desto trotz: Ratsam ist die Kompression natürlich (fast?) immer :-)

klar!

BTW: Zu dem Thread, dessen Überschrift du geändert hast: einer ist darauf aufmerksam
geworden :-)  hatte aber nix anzufügen, da du schon alles wesentliche gesagt hast. Und
ich hätte doch so gerne mitdiskutiert (spannendes Thema) :-((

Ja, fand ich auch, am Anfang wusste ich noch so gar nicht wie sowas funktioniert, am Ende hatte ich dann ne Menge gelernt ;-)

Ich hätte nicht gedacht dass man Umgebungsvariablen für sowas nutzt, ich dachte immer das wären sowas wie "Grundeinstellungen" des Terminals, halt ehrr so langfristige Geschichten :)

Grüße
Andreas

PS: Hast Du den Thread schon vor oder erst nach der Titel-Änderung gelesen? Hättest Du ihn sonst gelesen?

[Philipp Hasenfratz]

Halihallo Andreas

Hast Du mal probiert die Daten gzip-komprimiert auszugeben? Das bewirkt bei mir manchmal wahre Wunder ;-)

Öhhh, nein, zumindest nicht für dieses Problem. Aaaaaber: Wenn die Ausgabedaten korrupt
sind, dann stimmt die Checksum (falls eine gebildet ist, was bei Deflate IMHO nicht so
ist) nicht mehr, bzw. die Dekompression schlegt fehl oder gibt noch mehr Blödsinn aus.

Naja, ich hatte mal ein etwas ähnliches problem als ich das Synchonisations-Script zw. einem Windows und einem Unix-Server geschrieben habe(vielleicht erinnerst Du Dích ja noch ;-)),

Oh ja, ich mag mich erinnern :-)

da hatte ich zwischendurch ganz komische Probleme, was glaueb ich an irgendwelchen Fehlinterpretierten Zeilenumbrüchen lag(oder sowas in die Richtung, so ganz genau habe ich das nicht feststellen können). Naja, als ich das ganez dann komprimiert übertragen habe waren e dann halt binäre Daten, und ab da gab es keine Probleme mehr. Ich dachte vielleicht könnte das auch hier helfen...

Möglich wäre es schon, ja.

Ich hätte nicht gedacht dass man Umgebungsvariablen für sowas nutzt, ich dachte immer das wären sowas wie "Grundeinstellungen" des Terminals, halt ehrr so langfristige Geschichten :)

Stimmt ja auch. Nur ist es eben Standard geworden, dass CGI auch darauf zurückgreift.
Ich weiss jedoch nicht, warum CGI nicht über die Parameter kommuniziert? - Über die
Umgebungsvariablen zu kommunizieren halte ich für einen "Medienbruch" (Umgebungsvariablen
sind für alle Programme einer Shell-Sitzung gedacht, Parameter für ein einzelnes
Programm; folglich wäre für mich die Übergabe der Daten über Parameter "logischer").
Was jedoch dagegenspricht ist, dass die Parameter in wohl allen Programmierumgebungen
als Array vorliegen (argc und argv[] in C, @ARGV in Perl, ...). Der Umgebungsvariablen-
"Hash" wäre da schon viel "geeigneter", was wahrscheinlich am Schluss auch dazu führte,
dass es so vereinbahrt wurde.

PS: Hast Du den Thread schon vor oder erst nach der Titel-Änderung gelesen? Hättest Du ihn sonst gelesen?

Ohne Titel-Änderung hätte ich ihn wohl erst viel später gelesen oder ggf. ganz übersehen.
Die Titel-Änderung hat mich aber auf den Thread aufmerksam gemacht => ich habe ihn erst
nach der Änderung gelesen.

Viele Grüsse

Philipp
  <!-- derzeit krank im "Bett" liegend ;) -->

[Philipp Hasenfratz]

Halihallo Christian

Wenn ich diese Datei über Apache ausliefere, funktioniert alles
Wenn ich diese Datei mittels Perl-Script + Apache ausliefere, bricht der Browser nach ca. 5000-6000 Zeilen ab (immer an anderer Stelle).

Hm. Über die reine Auslieferung über den Apachen funktioniert es also? - Immer?
Wenn es immer ist, macht mich das doch stutzig. Da gäbe es mehrere Möglichkeiten:

• es hängt irgendwie mit den Headern zusammen
• der IE ignoriert bekanntlich den MIME-Typen und sieht, dass es ein Perl-Script ist,
    dann mag er eben lange ausgaben des Perl-Scriptes nicht... denkt sich vielleicht,
    dass die Daten schon wieder veraltet sind und lädt dann neu.
• es ist wirklich ein Problem im CGI-Interface (in anderen Browsern reproduzierbar?)
• hm. Wohl noch mehr...

Leider habe ich im Moment nicht die Zeit, aber dieses Problem werde ich mir, wenn niemand
sonst eine Lösung hat, nochmals im Detail vornehmen.

Eine Frage an dich/andere: Ist das Problem auf anderen Browsern reproduzierbar? - Diese
Antwort würde die Problematik schon stark einschränken.

Viele Grüsse

Philipp

[MudGuard]

Hi,

• der IE ignoriert bekanntlich den MIME-Typen

richtig (zumindest tut er das in vielen Fällen).

und sieht, dass es ein Perl-Script ist,

falsch. Woran sollte er das erkennen, da er ja nur die AUSGABEN des Perlscripts zu Gesicht bekommt?

cu,
Andreas

[Philipp Hasenfratz]

Halihallo MudGuard

und sieht, dass es ein Perl-Script ist,
falsch. Woran sollte er das erkennen, da er ja nur die AUSGABEN des Perlscripts zu Gesicht bekommt?

Eben nicht nur die Ausgabe. Die angeforderte URL auch und da er vorwiegend auf die Datei-
Extension achtet (.pl / .cgi) meint der IE zu wissen, dass es sich um ein serverseitiges
Program handelt.
Natürlich, es war nur ein Gedanke... Folgende Prämissen: Der IE zeigt die vom Apachen
direkt ausgelieferte html-datei an, beim CGI-Script weitert er sich und lädt ständig neu.
Wenn das Problem dann nicht auch auf anderen Browsern reproduzierbar ist und
Page-Rendering Probleme oder andere "internas" ausgeschlossen werden können; wäre dies
eine mögliche Ursache dessen nähere Betrachtung es sicher auch Wert wäre. Aber ich halte
dies für unwahrscheinlich.

Viele Grüsse

Philipp

[Andres Freund]

Moin Philipp,

Aber ich halte dies für unwahrscheinlich.

Vor allem sollte man dies leicht nachprüfen können, indem man das script einfach mal auf .html enden lässt (inklusive Serverseitiger einstellung ...) bzw. einfach den Namen des Scriptes als verzeichniss gebrauchen.... Wenn es dann nicht mehr auftritt, hat man das Problem...

Grüße Andres Freund

[Michael Schröpl]

Hi Christian,

PPS: Michael Schröpl hatte das gleiche Problem in 1999: http://forum.de.selfhtml.org/archiv/1999_3/t04823.htm
Leider führt dieser Archiveintrag zu keiner Lösung.

ich kann dazu nur ergänzen, daß ich seit längerer Zeit meine Apaches selbst baue und konfiguriere und dieses Problem nicht mehr habe ... an eine konkrete Lösung erinnere ich mich nicht mehr.

Viele Grüße
      Michael

[Philipp Hasenfratz]

Halihallo Michael

PPS: Michael Schröpl hatte das gleiche Problem in 1999: http://forum.de.selfhtml.org/archiv/1999_3/t04823.htm
Leider führt dieser Archiveintrag zu keiner Lösung.
ich kann dazu nur ergänzen, daß ich seit längerer Zeit meine Apaches selbst baue und konfiguriere und dieses Problem nicht mehr habe ... an eine konkrete Lösung erinnere ich mich nicht mehr.

Ich bin mir nicht sicher, dass es sich hier wirklich um das selbe Problem handelt. Es
sind doch einige Unterschiede (zumindest bei mir) festzustellen:

a) Du sagtest, dass die Ausgabe immer an derselben Stelle abbricht. Bei mir zumindest
   ist die Abbruchstelle variabel.
b) Der Abbruch wird ist bei mir gefolgt von einem Reload.
c) Bei mir war das Problem eigentlich (bzw. vorallem) beschränkt auf den IE.

Dies muss jedoch nicht bedeuten, dass die Probleme vollkommen verschiedener Natur sind.

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo

a) Du sagtest, dass die Ausgabe immer an derselben Stelle abbricht. Bei mir zumindest
   ist die Abbruchstelle variabel.
b) Der Abbruch wird ist bei mir gefolgt von einem Reload.
c) Bei mir war das Problem eigentlich (bzw. vorallem) beschränkt auf den IE.
Dies muss jedoch nicht bedeuten, dass die Probleme vollkommen verschiedener Natur sind.

Na toll, jetzt spinnen die anderen Browser auch plötzlich... Und der HTTP-Log zeigt,
dass (obwohl, auf diesen verlasse ich mich nicht) die Dateien schon vor dem Browser
zerstückelt werden.

Folglich mache ich hier Falschaussagen um Falschaussagen und versuche ohne Argumente
zu argumentieren. Ich zieh mich zurück und komme erst wieder, wenn ich _verlässliche_
Argumente/Beweise/Indizien/Lösungen habe... ;)

Viele Grüsse

Philipp

[Christian Schnagl]

Hallo an Alle!

Das Problem tritt bei allen Browsern auf. Netscape 6.2 und 7.0 schaffen allerdings mehr Zeilen als der IE. Wenn ich den Server unter Linux laufen lasse, funktioniert es bei allen Browsern.

Schön zu wissen, daß ich nicht der Einzige mit diesem Problem bin. Einen Webserver selbst zu programmieren halte ich aber dennoch für einen etwas übertriebenen Lösungsansatz :-)

Ich tippe auf einen Bug in der CGI-Schnittstelle vom Windows-Apache.

Vielen Dank für Euere Zeit !

Christian Schnagl

[Michael Schröpl]

Hi Christian,

Das Problem tritt bei allen Browsern auf. Netscape 6.2 und 7.0 schaffen allerdings mehr Zeilen als der IE. Wenn ich den Server unter Linux laufen lasse, funktioniert es bei allen Browsern.

binmode? (Gibst Du irgendwelche Steuerzeichen aus, die unter Windows die FILE-Schnittstelle durcheinander bringen?)

Viele Grüße
      Michael

[Christian Schnagl]

binmode? (Gibst Du irgendwelche Steuerzeichen aus, die unter Windows die FILE-Schnittstelle durcheinander bringen?)

Nein, keine Sonderzeichen. Der komplette Sourcecode ist im Beitrag abgebildet. Vielleicht gibt es eine Maximalgrenze von \n die man ausgeben darf...