nicht angemeldet
Bilder on the fly im IE
0 
Der Martin
0 0 Der Martin
0 0 Der Martin
0
0
0 
Struppi
Bilder on the fly im IE
HAllo!
wenn ich Bilder on the fly erstelle (<img src="../pfad/bilderstellung.php">) werden im Firefox alle angezeigt und im Internetexplorer nicht die, bei denen die Erstellung lange dauert. Da kommt dann immer nur ein Rahmen mit nem roten x drin. Wenn ich per rechtsklick auf "Bild anzeigen" gehe, kommen sie. Gibt es im IE einen timeout oder so den man evtl. hochsetzen kann?
Juli
-
Hallo,
wenn ich Bilder on the fly erstelle (<img src="../pfad/bilderstellung.php">) werden im Firefox alle angezeigt und im Internetexplorer nicht die, bei denen die Erstellung lange dauert.
dann muss das aber schon sehr, sehr lange dauern.
Gibt es im IE einen timeout oder so den man evtl. hochsetzen kann?
Es gibt einen Timeout, der liegt AFAIK aber weit jenseits der 30 Sekunden. Ob man den weiter erhöhen kann, weiß ich nicht.
Allerdings hilft es dem IE, wenn dein bilderzeugendes Script wenigstens den HTTP-Header schonmal sendet. Dann "sieht" der IE, dass die erwartete Antwort kommt, und der Timeout schlägt nicht mehr zu.Ciao,
Martin--
Der Alptraum jedes Computers:
"Mir war, als hätte ich gerade eine 2 gesehen."
-
Allerdings hilft es dem IE, wenn dein bilderzeugendes Script wenigstens den HTTP-Header schonmal sendet. Dann "sieht" der IE, dass die erwartete Antwort kommt, und der Timeout schlägt nicht mehr zu.
Überhaupt einen HTTP-Header zu schicken wäre vermutlich die Lösung, IE mag das nicht wenn er keinen Header bekommt, FF akzeptiert das.
--
for your security, this text has been encrypted by ROT13 twice.-
Hallo,
Allerdings hilft es dem IE, wenn dein bilderzeugendes Script wenigstens den HTTP-Header schonmal sendet. Dann "sieht" der IE, dass die erwartete Antwort kommt, und der Timeout schlägt nicht mehr zu.
Überhaupt einen HTTP-Header zu schicken wäre vermutlich die Lösung, IE mag das nicht wenn er keinen Header bekommt, FF akzeptiert das.nein, Unsinn. Es gibt keine HTTP-Kommunikation ohne Header; ein HTTP-Request oder -Response beginnt per definitionem *immer* mit einem Header. Ohne Header würde ein Client den ganzen Datenblock als Header zu interpretieren versuchen (und vermutlich daran scheitern).
Ciao,
Martin-
nein, Unsinn. Es gibt keine HTTP-Kommunikation ohne Header; ein HTTP-Request oder -Response beginnt per definitionem *immer* mit einem Header. Ohne Header würde ein Client den ganzen Datenblock als Header zu interpretieren versuchen (und vermutlich daran scheitern).
okay, ich habe mich missverständlich ausgedrückt.
ich ging davon aus dass der TS nicht *explizit* einen header geschickt hat, dementsprechend wird der standardheader geschickt, das ist natürlich richtig.
IE interessiert es jetzt nicht was da an daten rüber kommt sondern nimmt einfach den header, während ff anhand der daten herausfindet dass es sich um ein bild handelt.--
for your security, this text has been encrypted by ROT13 twice.-
Hallo,
okay, ich habe mich missverständlich ausgedrückt.
ich ging davon aus dass der TS nicht *explizit* einen header geschickt hat, dementsprechend wird der standardheader geschickt, das ist natürlich richtig.ach so, jetzt hab ich es auch verstanden.
IE interessiert es jetzt nicht was da an daten rüber kommt sondern nimmt einfach den header, während ff anhand der daten herausfindet dass es sich um ein bild handelt.
Umgekehrt, mein Lieber, umgekehrt. ;-)
Der Firefox richtet sich *ausschließlich* nach dem Content-Type, wenn er eine Ressource behandelt, so wie sich das gehört. Der IE richtet sich hauptsächlich danach, was er an dieser Stelle erwartet, und manchmal untersucht er noch mit ein bisschen Magie die Nutzdaten an sich, um den genauen Typ rauszufinden. Der tatsächlich übermittelte Content-Type ist ihm in den meisten Fällen schnurz.Beispiele:
* Liefere eine JPEG-Grafik mit dem Content-Type image/gif aus -
dem IE ist das egal, er zeigt das JPEG an.
* Liefere HTML-Quelltext als text/plain aus -
IE interpretiert das HTML trotzdem, Firefox zeigt brav den Quelltext an
* Liefere ein MPEG-Video als application/zip aus -
der IE wird dennoch den Mediaplayer anwerfen und das Video abspielenSo long,
Martin--
In Ägypten haben früher 150000 Leute 35 Jahre lang an einer Pyramide gearbeitet. Aber bei uns arbeiten doppelt so viele Leute doppelt so lange allein an der Baugenehmigung.
(Dieter Nuhr, deutscher Kabarettist)
-
Umgekehrt, mein Lieber, umgekehrt. ;-)
Der Firefox richtet sich *ausschließlich* nach dem Content-Type, wenn er eine Ressource behandelt, so wie sich das gehört. Der IE richtet sich hauptsächlich danach, was er an dieser Stelle erwartet, und manchmal untersucht er noch mit ein bisschen Magie die Nutzdaten an sich, um den genauen Typ rauszufinden.Ah, da war was...
Jetzt wo du es sagst fällt mir auf dass das immer der FF war der mir manchmal die GIFs oder PNGs als Text angezeigt hat wenn nicht explizit ein Content-Type gesetzt worden ist.Gab es nicht mal diese "interessante" Sicherheitslücke, wo man dem IE ein Bild unterschieben konnte, das eigentliche eine Textdatei mit Javascript war, welches dann ausgeführt wurde?
--
for your security, this text has been encrypted by ROT13 twice.-
Hallo,
Gab es nicht mal diese "interessante" Sicherheitslücke, wo man dem IE ein Bild unterschieben konnte, das eigentliche eine Textdatei mit Javascript war, welches dann ausgeführt wurde?
keine Ahnung, davon habe ich nichts mitbekommen. Aber ist das relevant? In einem ordentlichen Browser hat Javascript keinerlei Zugriffsmöglichkeiten, die über das Browserfenster hinausgehen.
Im IE auch nicht, es sei denn, man würde auch noch ActiveX zulassen. Und das käme ja schon fast einem digitalen Suizid gleich.
Deshalb als Gesamtfazit: So what?Wer Javascript aus unbekannten, nicht vertrauenswürdigen Quellen ausführen lässt, ist selber schuld (oder ahnungslos).
Wer die Voraussetzungen bietet, dass dieses Javascript (genauer: JScript) auf Interna seines Systems zugreifen kann, der sollte entweder seinen Admin vierteilen, oder ihm ist wahrscheinlich nicht mehr zu helfen.So long,
Martin--
Most experts agree: Any feature of a program that you can't turn off if you want to, is a bug.
Except with Microsoft, where it is just the other way round.
-
Aber ist das relevant? In einem ordentlichen Browser hat Javascript keinerlei Zugriffsmöglichkeiten, die über das Browserfenster hinausgehen.
Im IE auch nicht, es sei denn, man würde auch noch ActiveX zulassen. Und das käme ja schon fast einem digitalen Suizid gleich.
Deshalb als Gesamtfazit: So what?Folgendes Szenario:
Über ein ungesichertes Bilduploadskript lade ich diese Datei auf einen Server, das Bild wird "angezeigt", a.k.a. JS wird ausgeführt.
Dabei wird z.B. das action-attribut eines Loginforms umgebogen, jeder der sich jetzt einloggen will schickt mir seine Zugangsdaten.--
for your security, this text has been encrypted by ROT13 twice.
-
-
-
-
-
-
-
aber weit jenseits der 30 Sekunden
das ist bei mir wohl das Problem. Manche dauern länger. Die Anwendung läuft nur zu Überwachungszwecken im Intranet. Da ist Performance kein Thema.
Juli
-
-
wenn ich Bilder on the fly erstelle (<img src="../pfad/bilderstellung.php">) werden im Firefox alle angezeigt und im Internetexplorer nicht die, bei denen die Erstellung lange dauert. Da kommt dann immer nur ein Rahmen mit nem roten x drin. Wenn ich per rechtsklick auf "Bild anzeigen" gehe, kommen sie. Gibt es im IE einen timeout oder so den man evtl. hochsetzen kann?
Das hat mit Sicherheit nichts damit zu tun. Wichtiger ist ob der IE überhaupt mit dem Response was anfangen kann. D.h. um deine Frage zu beantworten müßten wir Wissen, was das Skript (../pfad/bilderstellung.php) für einen HTTP Header sendet.
Struppi.