nicht angemeldet
"malformed header" bei Flush-( $| )-Versuch
hallo
ich habe mir untenstehendes skript vom internet gezogen. leider funktioniert es bei mir nicht. im log-file steht, ich hätte den header falsch ausgegeben: "malformed header from script. Bad header=HTTP/1.1 200 OK: g:/webroot/cgi-bin/test.cgi". kann mir jemand den grund sagen, oder ein lauffähiges flushskript für den MSIE geben?
<code>
$| = 1;
print "$ENV{'SERVER_PROTOCOL'} 200 OK\n";
print "Server: $ENV{'SERVER_SOFTWARE'}\n";
print "Content-type:
multipart/x-mixed-replace;boundary=ARandomString\n\n";
print "--ARandomString\n";
@words = ("This", "is", "a", "test");
for ($loop = 0; $loop <= @words; $loop++)
{
print "Content-type: text/plain\n\n";
print "$words[$loop]\n";
sleep (1);
print "\n--ARandomString\n";
}
exit (0);
</code>
ich bin mit..
apache 1.3 für win
perl 5.6
winXP
..unterwegs.
mfg Flunsi
-
Halihallo
ich habe mir untenstehendes skript vom internet gezogen. leider funktioniert es bei mir nicht. im log-file steht, ich hätte den header falsch ausgegeben: "malformed header from script. Bad header=HTTP/1.1 200 OK: g:/webroot/cgi-bin/test.cgi". kann mir jemand den grund sagen, oder ein lauffähiges flushskript für den MSIE geben?
Das Problem liegt nicht beim Browser, sondern zwischen Script und Apache (wenn ich das richtig interpretiere. Die Fehlermeldung steht ja im log des Webservers, nicht?).
Desweiteren liegt das Problem nicht beim flush.$| = 1;
print "$ENV{'SERVER_PROTOCOL'} 200 OK\n";
print "Server: $ENV{'SERVER_SOFTWARE'}\n";
print "Content-type:
multipart/x-mixed-replace;boundary=ARandomString\n\n";
print "--ARandomString\n";
@words = ("This", "is", "a", "test");
for ($loop = 0; $loop <= @words; $loop++)
{
print "Content-type: text/plain\n\n";
print "$words[$loop]\n";
sleep (1);
print "\n--ARandomString\n";
}
exit (0);Also, was hat den Content-Type: multipart/x-mixed-replace in einer HTTP-Response zu suchen? - Glaube kaum, dass das den RFC-Spezifikationen entspricht. Was möchtest denn du damit machen?
Versuch einmal einfach die Kodierung auf text/html zu setzen. Wird dann immer noch eine Fehlermeldung ausgegeben???
Nun gut, ich kann mir eine Situation ausmalen, wo ein multipart/x-mixed-replace vorkommt. Das ist in diesen komischen .mht - Webarchiven des MSIE.
Viele Grüsse
Philipp
-
Moin!
Also, was hat den Content-Type: multipart/x-mixed-replace in einer HTTP-Response zu suchen? - Glaube kaum, dass das den RFC-Spezifikationen entspricht. Was möchtest denn du damit machen?
Das ist ein experimenteller Typ, welcher Server-Push ermöglicht. Der Client läßt die Verbindung zum Server offen, und dieser kann beliebig neue Seiten zum Client senden, welche dieser sofort neu anzeigt. Die bestehende Seite wird dabei ersetzt.
Leider (an dem "x-" im Content-Type zu erkennen) ist das eben nur ein experimenteller Typ, den der Internet Explorer niemals umgesetzt hat, sondern nur der Netscape (der es, da Erfindung von Netscape, seit Version 1.1 kann, aber mindestens seit Version 4 wohl nicht mehr).
Versuch einmal einfach die Kodierung auf text/html zu setzen. Wird dann immer noch eine Fehlermeldung ausgegeben???
Nun gut, ich kann mir eine Situation ausmalen, wo ein multipart/x-mixed-replace vorkommt. Das ist in diesen komischen .mht - Webarchiven des MSIE.
Wie gesagt: Völlig falsch, IE kann damit garnichts anfangen.
- Sven Rautenberg
-
Halihallo
Also, was hat den Content-Type: multipart/x-mixed-replace in einer HTTP-Response zu suchen? - Glaube kaum, dass das den RFC-Spezifikationen entspricht. Was möchtest denn du damit machen?
Das ist ein experimenteller Typ, welcher Server-Push ermöglicht. Der Client läßt die Verbindung zum Server offen, und dieser kann beliebig neue Seiten zum Client senden, welche dieser sofort neu anzeigt. Die bestehende Seite wird dabei ersetzt.
Ach so. Aber dann flackert's ja nur noch, es sei denn man hat eine sleep - Funktion eingebaut. Aber dann kriegt man schnell Probleme mit dem Servertimeout. Natürlich, dieses Format wäre toll für eine Slideshow, aber eben: Timeout's...
Also irgendwie verstehe ich den Sinn dieses "experimentellen Standards" nicht so ganz.Versuch einmal einfach die Kodierung auf text/html zu setzen. Wird dann immer noch eine Fehlermeldung ausgegeben???
Nun gut, ich kann mir eine Situation ausmalen, wo ein multipart/x-mixed-replace vorkommt. Das ist in diesen komischen .mht - Webarchiven des MSIE.
Wie gesagt: Völlig falsch, IE kann damit garnichts anfangen.
vollig nicht, aber falsch war's schon. Ich meinte nur, das IE auch etwas in dieser Art kennt. Einen Multipart in einem Dokument => damit legt er Webarchive an (Bilder/Sound/... und .html Dateien in einer Datei).
Viele Grüsse
Philipp
-
Hi!
Ach so. Aber dann flackert's ja nur noch, es sei denn man hat eine sleep - Funktion eingebaut. Aber dann kriegt man schnell Probleme mit dem Servertimeout. Natürlich, dieses Format wäre toll für eine Slideshow, aber eben: Timeout's...
Server lassen sich doch konfigurieren...
Also irgendwie verstehe ich den Sinn dieses "experimentellen Standards" nicht so ganz.
Man nennt sowas Server push. Erklaerung durch Gegenbeispiel: Mit dem META REFRESH im Quelltext kann man ein Neuanfordern der Seite durch den Browser veranlassen. Das nennt man Client pull, da der Client selbst entscheidet, ob und wann er neue Daten anfordert. Beim Server push wird ihm das eben vom Server reingedrueckt. Der sendet immer neue Daten, wenn er gerade welche hat. Anwendung sind staendig zu aktualisierende Daten, z.B. das Bild einer Webcam. Beispiel: http://www.uark.edu/~wrg/netscape/push.html (Das ist KEIN animiertes GIF!)
So long
-
Halihalo
Ach so. Aber dann flackert's ja nur noch, es sei denn man hat eine sleep - Funktion eingebaut. Aber dann kriegt man schnell Probleme mit dem Servertimeout. Natürlich, dieses Format wäre toll für eine Slideshow, aber eben: Timeout's...
Server lassen sich doch konfigurieren...
klar, aber die Verwendung dieses Formats hat schon implizit ein Programm zur Folge, welches enorm lange läuft. Also schon mal nicht sehr gut für WebServer. Es seidenn man könnte im Dateiformat selber ein Timeout angeben, das wäre natürlich schon wünschenswert.
Also irgendwie verstehe ich den Sinn dieses "experimentellen Standards" nicht so ganz.
Man nennt sowas Server push. Erklaerung durch Gegenbeispiel: Mit dem META REFRESH im Quelltext kann man ein Neuanfordern der Seite durch den Browser veranlassen. Das nennt man Client pull, da der Client selbst entscheidet, ob und wann er neue Daten anfordert. Beim Server push wird ihm das eben vom Server reingedrueckt. Der sendet immer neue Daten, wenn er gerade welche hat. Anwendung sind staendig zu aktualisierende Daten, z.B. das Bild einer Webcam. Beispiel: http://www.uark.edu/~wrg/netscape/push.html (Das ist KEIN animiertes GIF!)
Aha. So weit so gut. Aber gibt's auch schon fixierte Standards, oder ist diese "Technologie" noch in der Warteschlaufe des W3C??? - Na, ja, ich musste (glücklicherweise???) noch keine Anwendungen für eine Webcam programmieren ;)
Wobei man bei RealTime Charts das ganze schon ganz gut gebrauchen könnte. Nur leider wird bei jedem Request ein Program gestartet, dass dan endlos (oder zumindest sehr lange) weiterläuft. Daher löse ich diese Angelegenheit immer durch einen Client pull (Philipp hat ein neues Wort gelernt ;) )Viele Grüsse
Philipp
-
Hi Philipp,
Wobei man bei RealTime Charts das ganze schon ganz gut gebrauchen
könnte.In der Tat ...
Nur leider wird bei jedem Request ein Program gestartet,
dass dan endlos (oder zumindest sehr lange) weiterläuft.... aber auch die Kontrolle darüber hat, wie lange es schon läuft, und
ggf. nach Ablauf einer Maximaldauer aufhört (oder beispielsweise die
Push-Frequenz dynamisch anpaßt).Daher löse ich diese Angelegenheit immer durch einen Client pull
(Philipp hat ein neues Wort gelernt ;) )Wenn das Programm wie im Falle der Webcam nur in relativ großen oder
eventuell sogar in unvorhersehbaren Abständen neue Daten erzeugt, dann
ist es geschickter, die Übertragung ereignisgesteuert durchzuführen als
den Client pollen zu lassen. Und da die Ereignisse auf dem Server statt
finden, ist er es auch, der die Initiative übernehmen sollte.
(Daß in diesem Falle HTTP nicht unbedingt mehr das Protokoll meiner Wahl
wäre, ist eine andere Frage - ein Java-Applet könnte eine stehende Ver-
bindung halten.)Stell Dir vor, Du darfst bei Realtime-Börsenkursveränderungen eine
maximale Verzögerung von 2 Sekunden tolerieren, um den Anwender die
Realzeit-Eigenschaft zu garantieren (reichlich Bandbreite und einen
schnellen Server setzen wir mal voraus).
Dann müßte der Client alle 1-2 Sekunden pollen, ob auf dem Server etwas
passiert ist. Jetzt laß den Client in diesem Modus mal mehrere Dutzend
Titel beobachten!
Verglichen damit ist es wesentlich effizienter (sowohl für das Netz als
auch für den Server!), wenn der Server von sich aus neue Daten sendet,
falls welche vorhanden ist, anstatt dem Client ständig ein "nun warte
doch noch ein bißchen ..." zurück zu senden.Server Push ist m. E. eine Konzession an eine HTTP-Eigenheit von Leuten,
die HTTP für etwas verwenden wollen, wofür es nicht gedacht ist - weil
die Anwender nun mal einen HTTP-Browser auf der Festplatte haben und
Clients für andere, geeignetere Protokolle erst mal den Verbreitungsgrad
erreichen müßten, den die Browser heute schon haben.Der Webserver ist ja auch nicht dazu da, den Browsern pausenlos ein
munteres "HTTP-Status 304: Ja doch, Mensch - Dein Cache-Inhalt _ist_
noch gültig" zurück zu senden - deshalb gibt es in den Browsern die
Möglichkeit, die Häufigkeit (genauer gesagt; die Strategie) der
Validierungen dieses Caches selbst einzustellen ...Viele Grüße
Michael-
Halihallo Michael
Nur leider wird bei jedem Request ein Program gestartet,
dass dan endlos (oder zumindest sehr lange) weiterläuft.... aber auch die Kontrolle darüber hat, wie lange es schon läuft, und
ggf. nach Ablauf einer Maximaldauer aufhört (oder beispielsweise die
Push-Frequenz dynamisch anpaßt).Ja, da hast du völlig recht. Mich stört nur etwas, dass diese Programme derart lange laufen. Man stelle sich vor, man hat ein Börsen-Chart-Programm, welches in Abständen von 2 Sekunden Charts zurücksendet (und dies mindestens 20 Minuten macht). Dann ist es doch nicht unwahrscheinlich, dass innerhalb dieser 20 Minuten 100 Clienten kommen und somit immer _100_ Instanzen desselben Programms laufen. Hier wurde bei mir die Alarmglocke klingeln mit der Meldung: "Achtung, Serverüberlastung steht unmittelbar bevor". Vielleicht male ich hier etwas schwarz, aber wenn es _möglich ist_, würde ich den Client-pull dennoch vorziehen, mit all seinen Nachteilen.
[...]
Ich verstehe deine Argumentation sehr gut. Natürlich ist in den von dir genannten Beispielen der Server-push die *logischere* Wahl. Nur dass man bei grosser Besucherfrequenz die Serverfarmen sehr schnell ausbauen muss und ein load blancing installieren müsste.
Ich denke, dass dein Vorschlag zur Umsetzung mit JavaApplets der wohl beste Kompromiss darstellt.Viele Grüsse
Philipp
-
Hi Philipp,
Man stelle sich vor, man hat ein Börsen-Chart-Programm, welches in
Abständen von 2 Sekunden Charts zurücksendet (und dies mindestens
20 Minuten macht). Dann ist es doch nicht unwahrscheinlich, dass
innerhalb dieser 20 Minuten 100 Clienten kommen und somit immer
_100_ Instanzen desselben Programms laufen.
Hier wurde bei mir die Alarmglocke klingeln mit der Meldung:
"Achtung, Serverüberlastung steht unmittelbar bevor".
Vielleicht male ich hier etwas schwarz, aber wenn es _möglich ist_,
würde ich den Client-pull dennoch vorziehen, mit all seinen Nachteilen.Wenn der Kunde bereit ist, für einen solchen Dienst einen dedizierten
Server zu mieten (>100k Euro), wieso nicht?Ich verstehe deine Argumentation sehr gut. Natürlich ist in den von
dir genannten Beispielen der Server-push die *logischere* Wahl.Genau das zu zeigen war der Sinn meines Postings.
Nur dass man bei grosser Besucherfrequenz die Serverfarmen sehr schnell
ausbauen muss und ein load blancing installieren müsste.Richtig - das ist in der Tat eine der Konsequenzen.
Ich denke, dass dein Vorschlag zur Umsetzung mit JavaApplets der wohl
beste Kompromiss darstellt."Das hängt von der exakten Aufgabenstellung ab."
(Dies dürfte mein häufigster Satz im Büro sein - die Kollegen ziehen mich
schon auf mit dem "A-word" ... ;-)Viele Grüße
Michael-
Halihallo Michael
Man stelle sich vor, man hat ein Börsen-Chart-Programm, welches in
Abständen von 2 Sekunden Charts zurücksendet (und dies mindestens
20 Minuten macht). Dann ist es doch nicht unwahrscheinlich, dass
innerhalb dieser 20 Minuten 100 Clienten kommen und somit immer
_100_ Instanzen desselben Programms laufen.
Hier wurde bei mir die Alarmglocke klingeln mit der Meldung:
"Achtung, Serverüberlastung steht unmittelbar bevor".
Vielleicht male ich hier etwas schwarz, aber wenn es _möglich ist_,
würde ich den Client-pull dennoch vorziehen, mit all seinen Nachteilen.Wenn der Kunde bereit ist, für einen solchen Dienst einen dedizierten
Server zu mieten (>100k Euro), wieso nicht?Nun, weil das Preis-/Leistungsverhältnis sehr schlecht ist? - Ich meine, nur um Server-pushes zu gebrauchen extra Aufgeld zahlen? - Nun gut, wenn es die "Aufgabenstellung" nicht anders zulässt... muss man eben zahlen.
Ich denke, dass dein Vorschlag zur Umsetzung mit JavaApplets der wohl
beste Kompromiss darstellt."Das hängt von der exakten Aufgabenstellung ab."
Aber selbstverständlich ;)
(Dies dürfte mein häufigster Satz im Büro sein - die Kollegen ziehen mich
schon auf mit dem "A-word" ... ;-)Ach so, dann habe ich das von dir! - Irgendwie hast du mich auch mit diesem "Virus" infisziert ;)
Aber zumindest ist es ein begründbarer Virus; ich meine ein Virus, der recht hat.Viele Grüsse
Philipp
PS: Sorry für das verspätete Posting
-
es ist ja alles sehr interessant, was ihr da schreibt, aber ihr seid vom thema abgekommen.
ich hätte doch ganz gerne ein skript, dass einen flush auf dem MSIE sichtbar macht. so kann ich dann sehen, ob das problem bei mir oder dem IE liegt.
dankeMfG
FlunsiPS: Bitte, bitte, bitte und seid so lieb ;-). ich suche schon ne ewigkeit nach der lösung.
-
Hallihallo
es ist ja alles sehr interessant, was ihr da schreibt, aber ihr seid vom thema abgekommen.
'tschuldigung ;)
War grad sehr interessant ;)ich hätte doch ganz gerne ein skript, dass einen flush auf dem MSIE sichtbar macht. so kann ich dann sehen, ob das problem bei mir oder dem IE liegt.
Was ist denn hier die Rede vom flush??? - Der hat nur zur Konsequenz, dass die Programmausgaben nicht gecached werden und noch nicht einmal das ist sicher.
Es geht doch um einen Server-push, den du machen willst und dies ist leider mit dem IE (wurde einmal genannt) nicht möglich.Oder was möchtest du denn genau machen?
1. eben den Serverpush, der die Seite immer replaced
2. ein Script, dass die Daten immer _sofort_ ausliefert und so der Benutzer "realtime" sehen kann, was der Server-prozess macht?Viele Grüsse
Philipp
-
lolo
Oder was möchtest du denn genau machen?
- eben den Serverpush, der die Seite immer replaced
- ein Script, dass die Daten immer _sofort_ ausliefert und so der Benutzer "realtime" sehen kann, was der Server-prozess macht?
eher nr. 2, nur eine seite.
die seite sollte jedoch nicht erst angezeigt werden, wenn sie komplett ist, sondern sobald ein zeichen ausgegeben wird, soll der browser dieses auch gleich anzeigen.
zb. ein countdown, wobei zwischen den zahlen eine sekunde gewartet wird: 3..2..1..boom.ich vermute, dass der IE selbst einen Buffer hat und wartet bis dieser voll ist. wenn ich nämlich zb. beim countdown neben den zahlen noch etwa 4000 Bytes in form von leerzeichen mitsende, bekomme ich den gewünschten effekt. aber dass kann ja nicht die lösung sein!?
MfG. Flunsi
PS: hoffentlich liest das noch jemand, so weit unten.
-
Hallihallo
Oder was möchtest du denn genau machen?
- eben den Serverpush, der die Seite immer replaced
- ein Script, dass die Daten immer _sofort_ ausliefert und so der Benutzer "realtime" sehen kann, was der Server-prozess macht?
die seite sollte jedoch nicht erst angezeigt werden, wenn sie komplett ist, sondern sobald ein zeichen ausgegeben wird, soll der browser dieses auch gleich anzeigen.
zb. ein countdown, wobei zwischen den zahlen eine sekunde gewartet wird: 3..2..1..boom.ich vermute, dass der IE selbst einen Buffer hat und wartet bis dieser voll ist. wenn ich nämlich zb. beim countdown neben den zahlen noch etwa 4000 Bytes in form von leerzeichen mitsende, bekomme ich den gewünschten effekt. aber dass kann ja nicht die lösung sein!?
Hm. Ja, ich hatte genau das selbe Problem und leider gibt's dafür keine Lösung (etwas besser gesagt: keine guten, denn du hast ja eine gefunden). Das HTTP-Protokol, WebServer und Browser sind nunmal einfach nicht für diese Art von Tasks konzipiert worden.
Wenns dann aber um einen Countdown geht, habe ich dir noch ne Variante:
Sende mit perl ein HTML-Doku zurück mit einem JavaScript. Und Programmiere den Countdown mit JavaScript (den Anfangs- oder Initialwert kannst du ja mit perl ausgeben und im JS-Block als eine Variable ausgeben):
$count_begin = 09485; # or what ever...
print "<html><script src='countdown.js'></script>
<script>
var CountDownBegin=$count_begin;
startCountdown(); # function of countdown.js
</script> ...
</html>";im countdown.js - file hast du die Funktion startCountdown, welche den Countdown iniziiert.
Mit JS kann man solche Realtime-Effekte nämlich ganz einfach machen, mit perl als Server-Programmiersprache wirds etwas komplizierter.
PS: hoffentlich liest das noch jemand, so weit unten.
Ja, ja. Das wird schon noch gelesen, aber die Antworten dauern dann etwas länger, da der Thread ausser "Reichweite" gerät...
Viele Grüsse
Philipp
-
wololo
Wenns dann aber um einen Countdown geht, habe ich dir noch ne Variante:
Sende mit perl ein HTML-Doku zurück mit einem JavaScript. Und Programmiere den Countdown mit JavaScript (den Anfangs- oder Initialwert kannst du ja mit perl ausgeben und im JS-Block als eine Variable ausgeben):$count_begin = 09485; # or what ever...
print "<html><script src='countdown.js'></script>
<script>
var CountDownBegin=$count_begin;
startCountdown(); # function of countdown.js
</script> ...
</html>";danke, aber das war nur ein bsp. es geht eigentlich um eine serververarbeitung, wobei der server in regelmässigen abständen dem client sagt, "ja ich bin noch da, 30% wurde schon verarbeitet". nach dem alles verarbeitet wurde, kann die seite komplett ausgegeben werden. die verarbeitung dauert 1-3 min. da kann man den client nicht vor einem weissen bildschirm sitzen lassen.
mfg Flunsi
-
Hallihallo
danke, aber das war nur ein bsp. es geht eigentlich um eine serververarbeitung, wobei der server in regelmässigen abständen dem client sagt, "ja ich bin noch da, 30% wurde schon verarbeitet". nach dem alles verarbeitet wurde, kann die seite komplett ausgegeben werden. die verarbeitung dauert 1-3 min. da kann man den client nicht vor einem weissen bildschirm sitzen lassen.
Ja, das kann ich gut verstehen. Nur leider kenne ich wirklich keinen (einfachen) Weg um dieses Problem zu lösen.
Ich habe mal etwas gesehen x-drive.com (glaube ich), da konnte man zusehen, wie die Datei von Server zu Server übertragen wird; ich meine so eine schöne %-Anzeige.
Ich habe daraufhin gleich mal nachgedacht, wie man sowas macht und habe folgende Strategie entworfen:Dein Script (welches ca. 1-3 min. läuft) wird aufgerufen. Daraufhin wird die Ausgabe gleich mal auf ein anderes Script weitergeleitet, welches nur den aktuellen Status ausgibt (z. B. status.pl o. ä.). Die "Kommunikation" zwischen diesen beiden Programmen geschieht über eine Datei, welche auf dem Server gespeichert wird und nur die %-Angabe enthält (dein Script, schreibt den aktuellen Status alle 5 sek. o. so in diese Datei). Das status.pl - Script, gibt diesen Wert an den Klient weiter. Der Klient frägt nun (durch einen Refresh der Seite) alle 10 sek. o. so dieses status.pl Programm nach dem aktuellen Status ab.
Es ist zwar nicht die Lösung, welche du dir erhoffst, aber es ist auch eine Lösung. Andere sind mir leider nicht bekannt. Vielleicht solltest du einen neuen Thread mit dieser Frage eröffnen, wo du explizit das Problem nennst und nach deren Lösung fragst.
Viele Grüsse
Philipp
-
Hallihallo
danke, aber das war nur ein bsp. es geht eigentlich um eine serververarbeitung, wobei der server in regelmässigen abständen dem client sagt, "ja ich bin noch da, 30% wurde schon verarbeitet". nach dem alles verarbeitet wurde, kann die seite komplett ausgegeben werden. die verarbeitung dauert 1-3 min. da kann man den client nicht vor einem weissen bildschirm sitzen lassen.
Ja, das kann ich gut verstehen. Nur leider kenne ich wirklich keinen (einfachen) Weg um dieses Problem zu lösen.
Ich habe mal etwas gesehen x-drive.com (glaube ich), da konnte man zusehen, wie die Datei von Server zu Server übertragen wird; ich meine so eine schöne %-Anzeige.
Ich habe daraufhin gleich mal nachgedacht, wie man sowas macht und habe folgende Strategie entworfen:Dein Script (welches ca. 1-3 min. läuft) wird aufgerufen. Daraufhin wird die Ausgabe gleich mal auf ein anderes Script weitergeleitet, welches nur den aktuellen Status ausgibt (z. B. status.pl o. ä.). Die "Kommunikation" zwischen diesen beiden Programmen geschieht über eine Datei, welche auf dem Server gespeichert wird und nur die %-Angabe enthält (dein Script, schreibt den aktuellen Status alle 5 sek. o. so in diese Datei). Das status.pl - Script, gibt diesen Wert an den Klient weiter. Der Klient frägt nun (durch einen Refresh der Seite) alle 10 sek. o. so dieses status.pl Programm nach dem aktuellen Status ab.
Es ist zwar nicht die Lösung, welche du dir erhoffst, aber es ist auch eine Lösung. Andere sind mir leider nicht bekannt. Vielleicht solltest du einen neuen Thread mit dieser Frage eröffnen, wo du explizit das Problem nennst und nach deren Lösung fragst.
Ich habe mir genau das selbe auch schon mal kurz durch den Kopf gehen lassen. Aber 1. viel besser als die zusätzlichen-space-buffer-füll-methode ist diese refresh-methode auch nicht (ruckel, ruckel). und 2. ist das doch ein ganz grosser aufwand, mit der kommunikationsdatei auf dem server. und das alles nur für so eine blöde sache. ich wähle glaub provisorisch mal die space-methode. :-)
mfg Flunsi
-
Hallihallo
Ich habe mir genau das selbe auch schon mal kurz durch den Kopf gehen lassen. Aber 1. viel besser als die zusätzlichen-space-buffer-füll-methode ist diese refresh-methode auch nicht (ruckel, ruckel). und 2. ist das doch ein ganz grosser aufwand, mit der kommunikationsdatei auf dem server. und das alles nur für so eine blöde sache. ich wähle glaub provisorisch mal die space-methode. :-)
Ja, ich weiss, dass es sehr umständlich ist. Nur leider sehe ich wirklich kene andere Lösung. Nun, dann eben die space-methode, warum auch nicht? - Solange diese Methode einigermassen funktioniert, ist sie ja OK. Das einzige Problem ist halt, dass es die Länge der Datei ziemlich in die höhe treibt.
Viel Glück beim weiteren umsetzen
Philipp
-
-
-
Hi flunsi,
es geht eigentlich um eine serververarbeitung, wobei der server
in regelmässigen abständen dem client sagt, "ja ich bin noch da,
30% wurde schon verarbeitet". nach dem alles verarbeitet wurde,
kann die seite komplett ausgegeben werden. die verarbeitung
dauert 1-3 min. da kann man den client nicht vor einem weissen
bildschirm sitzen lassen.eine Verarbeitung, die 3 Minuten dauert, möchtest Du eigentlich ohnehin
nicht als CGI-Anwendung laufen lassen, sondern eher im Hintergrund.Aber die CGI-Anwendung kann sehr wohl auf die Ergebnisse dieser Ver-
arbeitung zugreifen dürfen (Dateien etc.) und anhand dieser Ergebnisse
(Dateigröße?) feststellen, wie weit der Prozeß 'gediehen' ist.
Das überwachende CGI-Skript braucht sich also nur periodisch selbst zu
laden (über META REFRESH, vielleicht alle 15 Sekunden) und den jeweili-
gen Zustand auszugeben. Und wenn das Skript erkennt, daß der Prozeß auf
dem Server fertig ist, dann läßt es den REFRESH-Header einfach weg.Viele Grüße
Michael
(der ein solches Verfahren produktiv einsetzt, sogar mit einem separaten
Frame als "refreshte Statuszeile" ... und sobald die Verarbeitung fertig
ist, wird in den "Hauptframe" eine Seite mit Links auf die erzeugten
Daten eingeblendet. Ja doch, Framesets haben auch ihre guten Seiten. ;-)-
Hi flunsi,
in regelmässigen abständen dem client sagt, "ja ich bin noch da,
Nachtrag zu diesem Aspekt:
Wenn das überwachende Skript die überwachten Objekte in Form von Dateien
sehen kann, dann kann es auch deren Änderungsdatum abfragen und anhand
dieser Information feststellen, wie lange die letzte Änderung zurück
liegt.
Sollte dies länger sein als ein normalerweise anzunehmendes Intervall,
aber der Endzustand auch noch nicht erreicht sein, dann kann der Über-
wacher die begründete Vermutung äußern, der Job sei möglicherweise abge-
stürzt ...Viele Grüße
Michael
-
-
-
-
-
-
-
-
-
-
-
-
Moin!
Also, was hat den Content-Type: multipart/x-mixed-replace in einer HTTP-Response zu suchen? - Glaube kaum, dass das den RFC-Spezifikationen entspricht. Was möchtest denn du damit machen?
Das ist ein experimenteller Typ, welcher Server-Push ermöglicht. Der Client läßt die Verbindung zum Server offen, und dieser kann beliebig neue Seiten zum Client senden, welche dieser sofort neu anzeigt. Die bestehende Seite wird dabei ersetzt.
Leider (an dem "x-" im Content-Type zu erkennen) ist das eben nur ein experimenteller Typ, den der Internet Explorer niemals umgesetzt hat, sondern nur der Netscape (der es, da Erfindung von Netscape, seit Version 1.1 kann, aber mindestens seit Version 4 wohl nicht mehr).
Versuch einmal einfach die Kodierung auf text/html zu setzen. Wird dann immer noch eine Fehlermeldung ausgegeben???
Nun gut, ich kann mir eine Situation ausmalen, wo ein multipart/x-mixed-replace vorkommt. Das ist in diesen komischen .mht - Webarchiven des MSIE.
Wie gesagt: Völlig falsch, IE kann damit garnichts anfangen.
- Sven Rautenberg
danke für die gute erklärung.
aber nun mal im ernst: geht flush bei MSIE überhaupt? so ein hallo-welt-skript: countdown: 3..sleep..2..sleep..1..sleep..boom! normal mit $| und text/html funzt es leider ned.mfg Flunsi
-
Hallihallo
aber nun mal im ernst: geht flush bei MSIE überhaupt? so ein hallo-welt-skript: countdown: 3..sleep..2..sleep..1..sleep..boom! normal mit $| und text/html funzt es leider ned.
Ach hier drückt der Schuh ;)
Leider nein. Aber das hat nix mit dem MSIE zu tun, sondern vielmehr mit dem Webserver. Wenn dieser die Daten cached (was oft der Fall ist), bringt auch der flush nix. Dann könnte noch ein kleines Problem in der Datenübertragung zum Clienten geschehen. TCP/IP (und alle anderen Protokolle) versenden Daten in Datenpacketen, somit ist schon ein kleiner "Cache" entstanden, der dein flush unwirksam macht.
So richtig "Real-time" wird's eben nie werden.
Viele Grüsse
Philipp
-
-
-
Hi!
print "$ENV{'SERVER_PROTOCOL'} 200 OK\n";
Der Response-Code wird IMHO mit
print "Status: 200\n";
ausgegeben.So long