auch Perl, Javascript; dyn. Bilddownload schlägt fehl (FF Linux)

[ritschmanhard]

HiHo!

Ich bin immer noch an meinem "dynamischen Bild" Problem (Thread ist aber mittlerweile ohne Antwort "verschwunden?"); aber, nachdem ich echt zum "Self" - ermittler der Problemlösungen werde, kann ich mein Problem immer besser definieren:

Kurzbeschreibung des Problems:
Client: -> parametrisierte Anfrage auf PNG (Client ist SuSe 9.3 + FF 2.0.6)
Server: erzeugt (dynamisch) & liefert PNG (Content-type: image/png\n\n) mittels Apache & Perl (command.cgi).
Dieses PNG wurde nicht serverseitig gespeichert und weist folgende Attribute auf:
alt="http://localhost/cgi-bin/command.cgi"
src="http://localhost/cgi-bin/command.cgi"

Das PNG wird nun in einen IFRAME zurückgeschrieben (ist sichtbar)
Wenn ich nun versuche, dieses Bild zu speichern, habe ich ein Problem:
versuche ich, das Bild oder den Frame zu speichern, dann wird keine Datei erzeugt (Bild/Frame speichern unter).
Allerdings wird mir der PNG Code (binär im FF Viewer) gezeigt, wenn ich  "Frame Quelltext Anzeigen" wähle - da dies aber kein binär-Editor ist, kann man aus ihm kein gültiges PNG speichern.

Versuchte Lösungsansätze:

1. Nun habe ich unter about:config versucht, mittels view_source.editor.path & view_source.editor.external den khexedit als Betrachter/Editor anzugeben. Dies geht auch, aber das erhaltene Binary wird (anscheinend) vom FF vorverarbeitet, so dass z.B. ein vorkommendes \0d\0a zu \0a umformatiert wird. => kein PNG :(

2. Ich habe mit das Addon ViewSourceWith geholt (und erneut khexedit als default editor eingetragen). Nun kommt das Gemeine: Wenn das Bild auf der Hauptseite liegt, so kann man mittels "Quelltext anzeigen mit" den PNG Code GÜLTIG mit khexedit ansehen/speichern. ABER: im IFRAME, wenn man versucht, dies zu tun, wird eine erneute (unparametrisierte) Anfrage an command.cgi gesendet; diese Anfrage beantwortet das CGI mit "204 No response", da ich die Grafik:
1. nicht nochmal erstellen will und
2. die benötigten Parameter nicht kenne
Folge: Ich erhalte wieder keine Anzeige, keine Daten.

3. Nun habe ich mich gefragt, ob ich den Bildknoten nach Empfang nicht "irgendwie" als Knoten auch in den Mainframe kopieren kann; aber auch hier macht mir der FF einen Strich durch die Rechnung:
Sei also das Bild im <IFRAME name="imgFrame"></IFRAME> geladen.
Ich klick einen Button, der das Bild in <div id="bild"> kopieren soll:<input onclick="copyImg()"/>
function copyImg()
{
  if (imgFrame.document.getElementsByTagName("img"))
  {
    var myClone = imgFrame.document.getElementsByTagName("img")[0].cloneNode(true);
    document.getElementbyId("bild").appendChild(myClone);
  }
}
Wie um mich zu ärgern, bekomme ich ganz kurz das Bild zu sehen; DANN aber wird wieder besagter Leeraufruf an command.cgi gesendet und ich sehe nur noch den alt="http://localhost/cgi-bin/command.cgi" Text.

Wenn ich speichern will, krieg ich wieder keine Datei...

Wie heißt es so schön in Radio BSR: "Isch bin hier langsam an Ende - der Combjudr macht was er will--die V(au)D(e)IAG(e).EXE kobiert sisch in die Gonfig.sys öhne eingeschdellde Inderrubds.".
Vielleicht hat ja einer von Euch noch ne Idee, wie ich diese !?*##x Bilder gespeichert bekomm.

Sorry für den unteren Absatz, aber ich bin echt gefrustet.

Viele Grüsse,
Richard

[Siechfred]

Kurzbeschreibung des Problems:
[...]

Ich mag deine alten Threads nicht ausgraben, aber: Grund Gütiger, was hast du vor?!

Was passiert, wenn du das Bild ganz normal einbindest, also via <img src="/cgi-bin/command.cgi">? Ist dann das Verhalten wie gewünscht? Existiert dein Problem nur im lokalen oder auch im WWW-Kontext?

Client: -> parametrisierte Anfrage auf PNG (Client ist SuSe 9.3 + FF 2.0.6)

Wo gibst du diese Parameter mit?

Server: erzeugt (dynamisch) & liefert PNG (Content-type: image/png\n\n) mittels Apache & Perl (command.cgi).

Soweit nachvollziehbar.

Dieses PNG wurde nicht serverseitig gespeichert und weist folgende Attribute auf:
alt="http://localhost/cgi-bin/command.cgi"
src="http://localhost/cgi-bin/command.cgi"

Auch hier die Frage: Woher kommen die Parameter?

Das PNG wird nun in einen IFRAME zurückgeschrieben (ist sichtbar)

Wie das? Perl kennt kein IFRAME, nur einen anfragenden Client.

versuche ich, das Bild oder den Frame zu speichern, dann wird keine Datei erzeugt (Bild/Frame speichern unter).
Allerdings wird mir der PNG Code (binär im FF Viewer) gezeigt, wenn ich  "Frame Quelltext Anzeigen" wähle - da dies aber kein binär-Editor ist, kann man aus ihm kein gültiges PNG speichern.

Klingt irgendwie nach einem MIME-Problem.

1. Nun habe ich unter about:config versucht, mittels view_source.editor.path & view_source.editor.external den khexedit als Betrachter/Editor anzugeben. Dies geht auch, aber das erhaltene Binary wird (anscheinend) vom FF vorverarbeitet, so dass z.B. ein vorkommendes \0d\0a zu \0a umformatiert wird. => kein PNG :(

Könnte es sein, dass FF Plaintext aus deinen Binärdaten macht?

2. Ich habe mit das Addon ViewSourceWith geholt (und erneut khexedit als default editor eingetragen). Nun kommt das Gemeine: Wenn das Bild auf der Hauptseite liegt, so kann man mittels "Quelltext anzeigen mit" den PNG Code GÜLTIG mit khexedit ansehen/speichern.

Und es kommt eine gültige PNG-Grafik raus?

ABER: im IFRAME, wenn man versucht, dies zu tun, wird eine erneute (unparametrisierte) Anfrage an command.cgi gesendet; diese Anfrage beantwortet das CGI mit "204 No response"

*Wie* bekommst du die Grafik in das IFRAME?

3. Nun habe ich mich gefragt, ob ich den Bildknoten nach Empfang nicht "irgendwie" als Knoten auch in den Mainframe kopieren kann; aber auch hier macht mir der FF einen Strich durch die Rechnung:

Klingt so, als ob der IFRAME aktualisiert wird.

Vielleicht hat ja einer von Euch noch ne Idee, wie ich diese !?*##x Bilder gespeichert bekomm.

Bestimmt, wenn man (ich) dein Konzept verstünde. Wie wäre es mal mit einem unverfänglichen Onlinebeispiel. Ach ja, tritt das Problem nur in der von dir genannten Testumgebung auf, oder auch mit anderen Browsern unter anderen Systemen?

Siechfred

[ritschmanhard]

Hi Siechfred!

Erstmal vielen, vielen Dank für's lesen.

Ich mag deine alten Threads nicht ausgraben, aber: Grund Gütiger, was hast du vor?!

*GGG*

Bevor ich jetzt die Fragen beantworte, vielleicht nochmal ein Erklärungsversuch mit Beispiel:

Auf dem Server liegt ein System, welches Daten erfasst. Mittels einer Eingabemaske (Formular) kann der Anwender nun z.B. eine Statistik für einen bestimmten Zeitraum erstellen lassen, welche als Grafik dargestellt wird.
Also ist der (bespielhafte, sehr vereinfachte) Aufbau des Clients:
(...)
<body>
<form name="anforderung" id="anforderung" target="imgFrame">
  <p>beginn der Auswertung <input name="start" type="text" value=""/></p>
  <p>ende der Auswertung <input name="end" type="text" value=""/></p>
  <input type="submit" value="submit"/>
</form>
<iframe name="imgFrame">
</iframe>
</body>
(...)

im CGI:
(...)
my $startVar = param('start');
my $endVar = param('end');

if (!defined $startVar || !defined $endVar)
{
   warn "Zefix, keine Params!";
   my $myCGI=new CGI;
   print $myCGI->header(-status=>'204 No response');
   exit(0);
}
my $pngContent = /usr/local/bin/genStat -start=$startVar -end=$endVar;

binmode stdout;
print "Content-Type: image/png\n\n"
print $pngContent;
exit(0);

Jetzt die Antworten:

Was passiert, wenn du das Bild ganz normal einbindest, also via <img src="/cgi-bin/command.cgi">?

Im Client: Nix
Im Server: es wird ins Error Log geschrieben: "Zefix, keine Params!"

Ist dann das Verhalten wie gewünscht?

Für diesen Aufruf schon, da ein unparametrisierter Aufruf keinen Sinn macht.

Existiert dein Problem nur im lokalen oder auch im WWW-Kontext?

Immer, wobei es nur einen localhost und einen Intranet Zugriff gibt.

Wo gibst du diese Parameter mit?

In dem dafür vorgesehenen Formular (siehe Beispiel).

Dieses PNG wurde nicht serverseitig gespeichert und weist folgende Attribute auf:
alt="http://localhost/cgi-bin/command.cgi"
src="http://localhost/cgi-bin/command.cgi"

Auch hier die Frage: Woher kommen die Parameter?

Keine Ahnung - ich gebe nur aus dem CGI wie oben beschrieben ein Bild zurück...

Das PNG wird nun in einen IFRAME zurückgeschrieben (ist sichtbar)
Wie das? Perl kennt kein IFRAME, nur einen anfragenden Client.

Ja, hatte ich halt schonmal beschrieben & dachte ich könnte es wegen vereinfachung weglassen, jetzt: siehe Beispiel (target="igmFrame").

versuche ich, das Bild oder den Frame zu speichern, dann wird keine Datei erzeugt (Bild/Frame speichern unter).
Allerdings wird mir der PNG Code (binär im FF Viewer) gezeigt, wenn ich  "Frame Quelltext Anzeigen" wähle - da dies aber kein binär-Editor ist, kann man aus ihm kein gültiges PNG speichern.
Klingt irgendwie nach einem MIME-Problem.

Ja? O, bitte, lass es eines sein... wie könnte ich dann den MIME type ändern, dass das Bild sich speichern lässt?

1. Nun habe ich unter about:config versucht, mittels view_source.editor.path & view_source.editor.external den khexedit als Betrachter/Editor anzugeben. Dies geht auch, aber das erhaltene Binary wird (anscheinend) vom FF vorverarbeitet, so dass z.B. ein vorkommendes \0d\0a zu \0a umformatiert wird. => kein PNG :(

Könnte es sein, dass FF Plaintext aus deinen Binärdaten macht?

Vermutlich - kann man das umgehen?

2. Ich habe mit das Addon ViewSourceWith geholt (und erneut khexedit als default editor eingetragen). Nun kommt das Gemeine: Wenn das Bild auf der Hauptseite liegt, so kann man mittels "Quelltext anzeigen mit" den PNG Code GÜLTIG mit khexedit ansehen/speichern.

Und es kommt eine gültige PNG-Grafik raus?

Wenn ich den Code in khexedit als png speichere und öffne: Ja.

ABER: im IFRAME, wenn man versucht, dies zu tun, wird eine erneute (unparametrisierte) Anfrage an command.cgi gesendet; diese Anfrage beantwortet das CGI mit "204 No response"
*Wie* bekommst du die Grafik in das IFRAME?

Siehe Beispiel (target="igmFrame")

Vielleicht hat ja einer von Euch noch ne Idee, wie ich diese !?*##x Bilder gespeichert bekomm.

Bestimmt, wenn man (ich) dein Konzept verstünde. Wie wäre es mal mit einem unverfänglichen Onlinebeispiel.

Leider kann ich den Server selbst nicht nach außen öffnen. Das Beispiel habe ich versucht zu geben.

Ach ja, tritt das Problem nur in der von dir genannten Testumgebung auf, oder auch mit anderen Browsern unter anderen Systemen?

Ob das Problem mit anderen Server-Konfigurationen auftritt, weiß ich nicht, aber das kann ich eh nicht ändern: es bleibt bei SuSe 9.3 und Apache - die apache Konfig darf ich zwar ändern, aber ich wüßte nicht, was ich dort machen sollte.
Bezüglich anderer Clients (auch im anderen Thread schon erwähnt): Unter Linux tritt das Problem mit FF 1.0 -2.x auf, mit Netscape 7.2 ebenfalls - andere Browser werden nicht unterstützt (ist ein Intranet Projekt, nicht fürs WWW).
Unter Windows (2k, XP) tritt der Fehler _nicht_ auf für FF 1.0-2.x, Netscape 7.1 und IE 6

vergleiche auch meine Posts: http://forum.de.selfhtml.org/archiv/2007/7/t157207/#m1022611
und
http://forum.de.selfhtml.org/archiv/2007/7/t157282/#m1023086

Danke und Grüsse,

Richard

[Siechfred]

Bevor ich jetzt die Fragen beantworte, vielleicht nochmal ein Erklärungsversuch mit Beispiel:

Aha, danke. Vorab noch zwei Fragen: Wenn du das Perl-Script direkt aufrufst (mit Parametern natürlich), dann ist alles i.O.? Hast du es schon mal mit einem anderen Grafikformat versucht?

im CGI:
(...)
my $startVar = param('start');
my $endVar = param('end');

if (!defined $startVar || !defined $endVar)
{
   warn "Zefix, keine Params!";
   my $myCGI=new CGI;
   print $myCGI->header(-status=>'204 No response');
   exit(0);
}
my $pngContent = /usr/local/bin/genStat -start=$startVar -end=$endVar;

Schreibe doch nur interessehalber den Inhalt von $pngContent in eine Datei und speichere diese ab. Wird diese dann als PNG erkannt?

Das PNG wird nun in einen IFRAME zurückgeschrieben (ist sichtbar)
Wie das? Perl kennt kein IFRAME, nur einen anfragenden Client.
Ja, hatte ich halt schonmal beschrieben & dachte ich könnte es wegen vereinfachung weglassen, jetzt: siehe Beispiel (target="igmFrame").

Wenn du die IFRAME-Spielereien mal weglässt oder als Target ein FRAME nimmst, besteht dann immer noch ein Problem?

Hast du schon mal versucht, dieses Backticks-Gedöns wegzulassen, und das Ganze so zu regulieren:

my $command = "/usr/local/bin/genStat -start=$startVar -end=$endVar 1>$id.png";  
[link:http://perldoc.perl.org/functions/system.html@title=system]( $command ) == 0 or die 'Failed';  
my $buf;  
print "Content-type: image/png\n\n";  
open(IMG, "<$id.png") or die $!;  
binmode(IMG);  
while(read IMG,$buf,8192) {  
  print $buf;  
}  
close IMG;

Also das Ergebnis der Operation serverseitig zwischenspeichern, $id wäre dann irgendeine temporäre Geschichte, hier könnte File::Temp helfen.

Viel mehr fällt mir dann leider auch nicht an möglichen Lösungsansätzen ein.

Siechfred

[ritschmanhard]

Hi Siechfred!

Schreibe doch nur interessehalber den Inhalt von $pngContent in eine Datei und speichere diese ab. Wird diese dann als PNG erkannt?

Hab ich schon mal gemacht; ja, das PNG ist OK. (Aber es wird ja auch von den Browsern als Bild dargestellt - nur speichern darf ich nicht).

Wenn du die IFRAME-Spielereien mal weglässt oder als Target ein FRAME nimmst, besteht dann immer noch ein Problem?

Ja, das Problem bleibt (bei Frames, jedoch nicht wenn ich auf die Mainpage zurückgebe, aber dann ist mein Selektionsformular weg...).

Hast du schon mal versucht, dieses Backticks-Gedöns wegzulassen, und das Ganze so zu regulieren:

Schon klar, aber ich will ja gerade keine Speicherung auf Festplatte - weil ich sonst bei möglichen Crashes Dateileichen produziere; warum gehe ich davon aus, dass was schiefgehen kann? Bei den angesprochenen Daten, über die eine Statistik erstellt wird, handelt es sich leider um ein nicht verlässliches Format... auch bremsen die dauernden Festplattenzugriffe das System.

Aber trotzdem Danke,

Richard

[Siechfred]

Wenn du die IFRAME-Spielereien mal weglässt oder als Target ein FRAME nimmst, besteht dann immer noch ein Problem?
Ja, das Problem bleibt (bei Frames, jedoch nicht wenn ich auf die Mainpage zurückgebe, aber dann ist mein Selektionsformular weg...).

Dann scheint das Problem tatsächlich in der Kombination aus target-Attribut und (I)Frame zu bestehen (evtl. ein Bug?). Was spricht dagegen, die Serverantwort auf eine vollständige Seite aufzubohren? Das bisschen mehr Traffic und das Neuladen der Seite dürften im Intranet doch egal sein.

Hast du schon mal versucht, dieses Backticks-Gedöns wegzulassen, und das Ganze so zu regulieren:
Schon klar, aber ich will ja gerade keine Speicherung auf Festplatte - weil ich sonst bei möglichen Crashes Dateileichen produziere; warum gehe ich davon aus, dass was schiefgehen kann? Bei den angesprochenen Daten, über die eine Statistik erstellt wird, handelt es sich leider um ein nicht verlässliches Format... auch bremsen die dauernden Festplattenzugriffe das System.

Es gibt performante Wege für temporäre Dateien, bei denen kein Datenmüll produziert wird. Einer wäre das bereits genannte Modul "File::Temp", ich würde es zumindest versuchen. Die Frage ist nämlich, was dir lieber ist: Das minimale Risiko von Dateileichen oder das ungleich höhere Risiko, dass der User seine Statistik entweder nicht sieht, oder er sie zwar sieht, aber nicht speichern kann.

Siechfred

[ritschmanhard]

Hi Siechfred!

Ich hab's doch noch gebacken bekommen.
Zunächst das grundsätzliche, nicht erkannte Problem:

1. expires hatte ich in der CGI Antwort (Header) nicht gesetzt; dies bewirkt, dass dieser Wert = 0 ist (1.1.1970...) und deshalb (korrekt) eine Neuanfrage forciert und nichts vom Cache genommen wird.

2. wie schon so oft, verhalten sich also Linux und Firefox korrekt und Windows + IE nicht, obwohl man zwar das Verhalten von W+IE haben wollte, aber das von L+FF angefordert hat *G*.

Trotzdem ein fettes Merci für die Hilfe,

Richard