Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
OT: IE9 Requests
51 views
Skip to first unread message
W. Wolf
Dec 13, 2011, 6:43:43 AM12/13/11
to
Hallo,
hier vermutlich OT, aber irgendwo muss ich anfangen, weil ich mein
Problem noch nicht mal richtig einordnen kann. Bitte daher um Nachsicht...
Folgende Funktion sendet ein Formular per POST ab:
function GetSite(e) {
document.main.siteGUID.value=e;
document.main.submit();
}
Die Funktion GetSite wird wie folgt aufgerufen:
<a href="javascript:GetSite('F3DCD743...')">
und das HTML für die Form:
<form name="main" action="getSite" method="post">
der Server wertet siteGUID aus, ändert im Header die Location und sendet
einen 303. Der neue Response ist eine normale XHTML-Seite mit Verweisen
im Header, nichts Besonderes:
<link rel="stylesheet" type="text/css" href="standard.css" />
<script type="text/javascript" src="el.min.js"></script>
Das funktioniert auf allen bisher getesteten Browsern, mit einer
Einschränkung: Der IE9, und auch dieser nur im Browsermodus 9, macht
Probleme beim Download der beiden Verweise. In der Netzwerk-Aufzeichnung
des IE wird in der Spalte Ergebnis "(Abgebrochen)" angezeigt. Später
werden die beiden Verweise erneut vom IE angefordert, in der
Detailansicht schreibt der IE dazu (Initiator): "Dieser Download wurde
nach einem Neustart des Preparsers ausgeführt (oftmals aufgrund des
Umschaltens des Dokumentmodus oder fehlerhafter Inhaltscodierung
zwischen einem Meta-Tag im Dokument und der Stückliste oder einem
Serverheader)."
Dieser (zweite) Download funktioniert dann auch und die Seite wird
korrekt angezeigt. Das Ganze bekommt der Anwender nur deshalb mit, weil
der IE gute 5 Sekunden auf die ersten beiden Downloads wartet.
Auf dem Server sind die vier (zwei x zwei) Requests zu sehen und werden
auch abgearbeitet und ausgeliefert.
In der Zusammenfassung: Der "Fehler" passiert nur in dieser
Konstellation: Nach einen POST gefolgt von einer Weiterleitung (303) und
nur im IE-Modus 9. Wenn ich im Debugger den Modus 7 oder 8 einschalte,
ist alles normal.
Hat jemand hier so was schon mal gesehen? Kann mir jemand einen Tipp
geben, nach was ich recherchieren soll? Die Scripte werden ja kaum die
Ursache für dieses Verhalten sein. Kann ich diese zumindest ausschließen
(was meine Frage hier in der js-NG rechtfertigen soll)?
Schönen Gruß
W. Wolf
hier vermutlich OT, aber irgendwo muss ich anfangen, weil ich mein
Problem noch nicht mal richtig einordnen kann. Bitte daher um Nachsicht...
Folgende Funktion sendet ein Formular per POST ab:
function GetSite(e) {
document.main.siteGUID.value=e;
document.main.submit();
}
Die Funktion GetSite wird wie folgt aufgerufen:
<a href="javascript:GetSite('F3DCD743...')">
und das HTML für die Form:
<form name="main" action="getSite" method="post">
der Server wertet siteGUID aus, ändert im Header die Location und sendet
einen 303. Der neue Response ist eine normale XHTML-Seite mit Verweisen
im Header, nichts Besonderes:
<link rel="stylesheet" type="text/css" href="standard.css" />
<script type="text/javascript" src="el.min.js"></script>
Das funktioniert auf allen bisher getesteten Browsern, mit einer
Einschränkung: Der IE9, und auch dieser nur im Browsermodus 9, macht
Probleme beim Download der beiden Verweise. In der Netzwerk-Aufzeichnung
des IE wird in der Spalte Ergebnis "(Abgebrochen)" angezeigt. Später
werden die beiden Verweise erneut vom IE angefordert, in der
Detailansicht schreibt der IE dazu (Initiator): "Dieser Download wurde
nach einem Neustart des Preparsers ausgeführt (oftmals aufgrund des
Umschaltens des Dokumentmodus oder fehlerhafter Inhaltscodierung
zwischen einem Meta-Tag im Dokument und der Stückliste oder einem
Serverheader)."
Dieser (zweite) Download funktioniert dann auch und die Seite wird
korrekt angezeigt. Das Ganze bekommt der Anwender nur deshalb mit, weil
der IE gute 5 Sekunden auf die ersten beiden Downloads wartet.
Auf dem Server sind die vier (zwei x zwei) Requests zu sehen und werden
auch abgearbeitet und ausgeliefert.
In der Zusammenfassung: Der "Fehler" passiert nur in dieser
Konstellation: Nach einen POST gefolgt von einer Weiterleitung (303) und
nur im IE-Modus 9. Wenn ich im Debugger den Modus 7 oder 8 einschalte,
ist alles normal.
Hat jemand hier so was schon mal gesehen? Kann mir jemand einen Tipp
geben, nach was ich recherchieren soll? Die Scripte werden ja kaum die
Ursache für dieses Verhalten sein. Kann ich diese zumindest ausschließen
(was meine Frage hier in der js-NG rechtfertigen soll)?
Schönen Gruß
W. Wolf
Thomas 'PointedEars' Lahn
Dec 13, 2011, 7:11:54 AM12/13/11
to
W. Wolf wrote:
^^
Da fe lt was.
> Folgende Funktion sendet ein Formular per POST ab:
> function GetSite(e) {
> document.main.siteGUID.value=e;
> document.main.submit();
> }
> Die Funktion GetSite wird wie folgt aufgerufen:
> <a href="javascript:GetSite('F3DCD743...')">
> und das HTML für die Form:
> <form name="main" action="getSite" method="post">
Richtiger Ansatz:
<form action="getSite" method="post">
<button type="submit" name="siteGUID" value="…">…</button>
…
</form>
Kein clientseitiges Script und kein fehlerträchtiger `javascript:'-URI
notwendig.
> der Server wertet siteGUID aus, ändert im Header die Location und sendet
> einen 303.
ACK.
> Der neue Response ist eine normale XHTML-Seite mit Verweisen
> im Header,
Das ist _nicht_ der Header der HTTP-Response, sondern das head-Element der
Ressource (des XHTML-_Dokuments_).
> nichts Besonderes:
> <link rel="stylesheet" type="text/css" href="standard.css" />
> <script type="text/javascript" src="el.min.js"></script>
>
> Das funktioniert auf allen bisher getesteten Browsern, mit einer
> Einschränkung: Der IE9, und auch dieser nur im Browsermodus 9,
IE/MSHTML unterstützt XHTML nicht.
> macht Probleme beim Download der beiden Verweise.
Verweise werden nicht heruntergeladen, …
> In der Netzwerk-Aufzeichnung des IE wird in der Spalte Ergebnis
> "(Abgebrochen)" angezeigt. Später werden die beiden Verweise erneut vom IE
> angefordert,
… sondern _Ressourcen_ werden _über URIs_ angefordert.
> in der Detailansicht schreibt der IE dazu (Initiator): "Dieser Download
> wurde nach einem Neustart des Preparsers ausgeführt (oftmals aufgrund des
> Umschaltens des Dokumentmodus oder fehlerhafter Inhaltscodierung zwischen
> einem Meta-Tag im Dokument und der Stückliste oder einem Serverheader)."
Du hast ein Problem mit IE (und dessen grottenschlechter Übersetzung –
"Stückliste"?) oder Deinem Server; eher nicht mit clientseitigem Scripting.
Die Ursache könnte sich aber auch in Deinem Code befinden, den Du weder
gepostet noch referenziert hast. Und meine Kristallkugel ist schon in den
Weihnachtsferien (die hatte dieses Jahr sehr viel zu tun, gönnen wir ihr
also die Pause).
<http://glasgoogle.de/>
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
^^
Da fe lt was.
> Folgende Funktion sendet ein Formular per POST ab:
> function GetSite(e) {
> document.main.siteGUID.value=e;
> document.main.submit();
> }
> Die Funktion GetSite wird wie folgt aufgerufen:
> <a href="javascript:GetSite('F3DCD743...')">
> und das HTML für die Form:
> <form name="main" action="getSite" method="post">
<form action="getSite" method="post">
<button type="submit" name="siteGUID" value="…">…</button>
…
</form>
Kein clientseitiges Script und kein fehlerträchtiger `javascript:'-URI
notwendig.
> der Server wertet siteGUID aus, ändert im Header die Location und sendet
> einen 303.
> Der neue Response ist eine normale XHTML-Seite mit Verweisen
> im Header,
Ressource (des XHTML-_Dokuments_).
> nichts Besonderes:
> <link rel="stylesheet" type="text/css" href="standard.css" />
> <script type="text/javascript" src="el.min.js"></script>
>
> Das funktioniert auf allen bisher getesteten Browsern, mit einer
> Einschränkung: Der IE9, und auch dieser nur im Browsermodus 9,
> macht Probleme beim Download der beiden Verweise.
> In der Netzwerk-Aufzeichnung des IE wird in der Spalte Ergebnis
> "(Abgebrochen)" angezeigt. Später werden die beiden Verweise erneut vom IE
> angefordert,
> in der Detailansicht schreibt der IE dazu (Initiator): "Dieser Download
> wurde nach einem Neustart des Preparsers ausgeführt (oftmals aufgrund des
> Umschaltens des Dokumentmodus oder fehlerhafter Inhaltscodierung zwischen
> einem Meta-Tag im Dokument und der Stückliste oder einem Serverheader)."
"Stückliste"?) oder Deinem Server; eher nicht mit clientseitigem Scripting.
Die Ursache könnte sich aber auch in Deinem Code befinden, den Du weder
gepostet noch referenziert hast. Und meine Kristallkugel ist schon in den
Weihnachtsferien (die hatte dieses Jahr sehr viel zu tun, gönnen wir ihr
also die Pause).
<http://glasgoogle.de/>
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Martin Honnen
Dec 13, 2011, 7:16:07 AM12/13/11
to
W. Wolf wrote:
> Folgende Funktion sendet ein Formular per POST ab:
> function GetSite(e) {
> document.main.siteGUID.value=e;
> document.main.submit();
> }
> Die Funktion GetSite wird wie folgt aufgerufen:
> <a href="javascript:GetSite('F3DCD743...')">
> und das HTML für die Form:
> <form name="main" action="getSite" method="post">
>
> der Server wertet siteGUID aus, ändert im Header die Location und sendet
> einen 303. Der neue Response ist eine normale XHTML-Seite mit Verweisen
> im Header, nichts Besonderes:
> <link rel="stylesheet" type="text/css" href="standard.css" />
> <script type="text/javascript" src="el.min.js"></script>
> Folgende Funktion sendet ein Formular per POST ab:
> function GetSite(e) {
> document.main.siteGUID.value=e;
> document.main.submit();
> }
> Die Funktion GetSite wird wie folgt aufgerufen:
> <a href="javascript:GetSite('F3DCD743...')">
> und das HTML für die Form:
> <form name="main" action="getSite" method="post">
>
> der Server wertet siteGUID aus, ändert im Header die Location und sendet
> einen 303. Der neue Response ist eine normale XHTML-Seite mit Verweisen
> im Header, nichts Besonderes:
> <link rel="stylesheet" type="text/css" href="standard.css" />
> <script type="text/javascript" src="el.min.js"></script>
> In der Zusammenfassung: Der "Fehler" passiert nur in dieser
> Konstellation: Nach einen POST gefolgt von einer Weiterleitung (303) und
> nur im IE-Modus 9. Wenn ich im Debugger den Modus 7 oder 8 einschalte,
> ist alles normal.
>
> Hat jemand hier so was schon mal gesehen? Kann mir jemand einen Tipp
> geben, nach was ich recherchieren soll? Die Scripte werden ja kaum die
> Ursache für dieses Verhalten sein. Kann ich diese zumindest ausschließen
> (was meine Frage hier in der js-NG rechtfertigen soll)?
Ob der Fehler vom obigen Scriptcode in dem Link abhängt, sollte sich
> Konstellation: Nach einen POST gefolgt von einer Weiterleitung (303) und
> nur im IE-Modus 9. Wenn ich im Debugger den Modus 7 oder 8 einschalte,
> ist alles normal.
>
> Hat jemand hier so was schon mal gesehen? Kann mir jemand einen Tipp
> geben, nach was ich recherchieren soll? Die Scripte werden ja kaum die
> Ursache für dieses Verhalten sein. Kann ich diese zumindest ausschließen
> (was meine Frage hier in der js-NG rechtfertigen soll)?
einfach ermitteln lassen, indem man mal statt des Links mit dem
Scriptaufruf das Formular einfach per
<form name="main" action="getSite" method="post">
<input type="hidden" name="siteGUID" value="F3DCD743...">
...
<input type="submit">
</form>
vom Browser versenden lässt.
Da der Fehler mit dem Download danach nicht nur bei der Script-Datei,
sondern auch bei der CSS-Datei auftritt, ist das dann ja offensichtlich
kein Scriptproblem.
Was die Fehlermeldung angeht, wie genau sieht denn der Anfang der "ganz
normalen XHTML-Seite" aus, und mit welchem Content-Type wird diese
ausgeliefert?
W. Wolf
Dec 13, 2011, 7:45:01 AM12/13/11
to
Am 13.12.2011 13:11, schrieb Thomas 'PointedEars' Lahn:
> W. Wolf wrote:
[...]
Funktion getSite() soll aber noch weitere Aufgaben bekommen, wenn erst
einmal das "Triviale" tut.
Die Vermutung das es an der Kombination IE/Server liegt hatte ich auch.
Meine Vorabrecherche hat unter anderen auch diese Seite gefunden:
http://www.magentocommerce.com/boards/viewthread/3374/
(s. ganz unten), deshalb die JS-Spekulation hier (was mir aber nicht
weiter geholfen hat).
Werde mal versuchen testweise vollkommen auf das Script zu verzichten.
Und meine Kristallkugel ist schon in den
> Weihnachtsferien (die hatte dieses Jahr sehr viel zu tun, gönnen wir ihr
> also die Pause).
>
Einverstanden! Sie hat es verdient ;-)
Immerhin, vielen Dank für die semantischen Korrekturen.
Schönen Gruß
W. Wolf
> W. Wolf wrote:
[...]
>
> Du hast ein Problem mit IE (und dessen grottenschlechter Übersetzung –
> "Stückliste"?) oder Deinem Server; eher nicht mit clientseitigem Scripting.
> Die Ursache könnte sich aber auch in Deinem Code befinden, den Du weder
> gepostet noch referenziert hast.
Es gibt (noch) keine weiteren Scripts, alles andere ist (nur) HTML. Die
> Du hast ein Problem mit IE (und dessen grottenschlechter Übersetzung –
> "Stückliste"?) oder Deinem Server; eher nicht mit clientseitigem Scripting.
> Die Ursache könnte sich aber auch in Deinem Code befinden, den Du weder
> gepostet noch referenziert hast.
Funktion getSite() soll aber noch weitere Aufgaben bekommen, wenn erst
einmal das "Triviale" tut.
Die Vermutung das es an der Kombination IE/Server liegt hatte ich auch.
Meine Vorabrecherche hat unter anderen auch diese Seite gefunden:
http://www.magentocommerce.com/boards/viewthread/3374/
(s. ganz unten), deshalb die JS-Spekulation hier (was mir aber nicht
weiter geholfen hat).
Werde mal versuchen testweise vollkommen auf das Script zu verzichten.
Und meine Kristallkugel ist schon in den
> Weihnachtsferien (die hatte dieses Jahr sehr viel zu tun, gönnen wir ihr
> also die Pause).
>
Immerhin, vielen Dank für die semantischen Korrekturen.
Schönen Gruß
W. Wolf
W. Wolf
Dec 13, 2011, 7:51:06 AM12/13/11
to
Am 13.12.2011 13:16, schrieb Martin Honnen:
[...]
> Da der Fehler mit dem Download danach nicht nur bei der Script-Datei,
> sondern auch bei der CSS-Datei auftritt, ist das dann ja offensichtlich
> kein Scriptproblem.
>
> Was die Fehlermeldung angeht, wie genau sieht denn der Anfang der "ganz
> normalen XHTML-Seite" aus, und mit welchem Content-Type wird diese
> ausgeliefert?
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
<meta http-equiv="Content-Script-Type" content="text/javascript" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<meta http-equiv="expires" content="0" />
<meta http-equiv="content-language" content="de" />
Schönen Gruß
W. Wolf
[...]
>
> Ob der Fehler vom obigen Scriptcode in dem Link abhängt, sollte sich
> einfach ermitteln lassen, indem man mal statt des Links mit dem
> Scriptaufruf das Formular einfach per
> <form name="main" action="getSite" method="post">
> <input type="hidden" name="siteGUID" value="F3DCD743...">
> ...
> <input type="submit">
> </form>
> vom Browser versenden lässt.
>
Danke, das werde ich mal testen.
> Ob der Fehler vom obigen Scriptcode in dem Link abhängt, sollte sich
> einfach ermitteln lassen, indem man mal statt des Links mit dem
> Scriptaufruf das Formular einfach per
> <form name="main" action="getSite" method="post">
> <input type="hidden" name="siteGUID" value="F3DCD743...">
> ...
> <input type="submit">
> </form>
> vom Browser versenden lässt.
>
> Da der Fehler mit dem Download danach nicht nur bei der Script-Datei,
> sondern auch bei der CSS-Datei auftritt, ist das dann ja offensichtlich
> kein Scriptproblem.
>
> Was die Fehlermeldung angeht, wie genau sieht denn der Anfang der "ganz
> normalen XHTML-Seite" aus, und mit welchem Content-Type wird diese
> ausgeliefert?
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
<meta http-equiv="Content-Script-Type" content="text/javascript" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<meta http-equiv="expires" content="0" />
<meta http-equiv="content-language" content="de" />
<link rel="stylesheet" type="text/css" href="standard.css" />
...
Schönen Gruß
W. Wolf
Martin Honnen
Dec 13, 2011, 7:59:03 AM12/13/11
to
W. Wolf wrote:
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
> <head>
> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
> <meta http-equiv="Content-Script-Type" content="text/javascript" />
> <meta http-equiv="Content-Style-Type" content="text/css" />
> <meta http-equiv="expires" content="0" />
> <meta http-equiv="content-language" content="de" />
> <link rel="stylesheet" type="text/css" href="standard.css" />
Das sieht soweit in Ordnung aus. Sendet der Server eventuelle HTTP
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
> <head>
> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1" />
> <meta http-equiv="Content-Script-Type" content="text/javascript" />
> <meta http-equiv="Content-Style-Type" content="text/css" />
> <meta http-equiv="expires" content="0" />
> <meta http-equiv="content-language" content="de" />
> <link rel="stylesheet" type="text/css" href="standard.css" />
header, die dem widersprechen (also etwa Content-Type:
application/xhtml+xml oder eventuell zumindest einen anderen
charset-Parameter)? Darauf könnte die Fehlermeldung "Neustart des
Preparsers ..." hindeuten.
--
Martin Honnen --- MVP Data Platform Development
http://msmvps.com/blogs/martin_honnen/
W. Wolf
Dec 13, 2011, 8:35:10 AM12/13/11
to
Am 13.12.2011 13:59, schrieb Martin Honnen:
[...]
für die standard.css
Content-Type text/css
für die js:
Content-Type application/x-javascript
komisch ist ja nur, dass die Seiten vernünftig laden, wenn ich diese
direkt aufrufe, also die URL in den Browser eingebe. Zu der Auszeit
kommt es ja nur in der Kombination mit dem vorangegangenen POST & 303.
Ich werde das alles noch mal versuchen stärker einzugrenzen. JS raus,
POST raus und mal mit GET testen usw.
Melde mich, wenn ich mehr habe. Hatte halt so ein bisschen auf eine
Antwort wie "Ach ja, das kennen wir, das liegt an..." gehofft. Macht
nichts, die Anregungen hier helfen mir schon mal weiter. Danke!
Schönen Gruß
W. Wolf
[...]
>
> Das sieht soweit in Ordnung aus. Sendet der Server eventuelle HTTP
> header, die dem widersprechen (also etwa Content-Type:
> application/xhtml+xml oder eventuell zumindest einen anderen
> charset-Parameter)? Darauf könnte die Fehlermeldung "Neustart des
> Preparsers ..." hindeuten.
>
>
Firebug zeigt mir:
> Das sieht soweit in Ordnung aus. Sendet der Server eventuelle HTTP
> header, die dem widersprechen (also etwa Content-Type:
> application/xhtml+xml oder eventuell zumindest einen anderen
> charset-Parameter)? Darauf könnte die Fehlermeldung "Neustart des
> Preparsers ..." hindeuten.
>
>
für die standard.css
Content-Type text/css
für die js:
Content-Type application/x-javascript
komisch ist ja nur, dass die Seiten vernünftig laden, wenn ich diese
direkt aufrufe, also die URL in den Browser eingebe. Zu der Auszeit
kommt es ja nur in der Kombination mit dem vorangegangenen POST & 303.
Ich werde das alles noch mal versuchen stärker einzugrenzen. JS raus,
POST raus und mal mit GET testen usw.
Melde mich, wenn ich mehr habe. Hatte halt so ein bisschen auf eine
Antwort wie "Ach ja, das kennen wir, das liegt an..." gehofft. Macht
nichts, die Anregungen hier helfen mir schon mal weiter. Danke!
Schönen Gruß
W. Wolf
Holger Jeromin
Dec 13, 2011, 8:54:13 AM12/13/11
to
W. Wolf schrieb am 13.12.2011 14:35:
> Am 13.12.2011 13:59, schrieb Martin Honnen:
> [...]
> Am 13.12.2011 13:59, schrieb Martin Honnen:
> [...]
> direkt aufrufe, also die URL in den Browser eingebe. Zu der Auszeit
> kommt es ja nur in der Kombination mit dem vorangegangenen POST& 303.
Vielleicht hilft dir auch das ie internals Blog. Auch wenn da kein
> kommt es ja nur in der Kombination mit dem vorangegangenen POST& 303.
Unterschied zwischen 6 bis 10 beschrieben wird:
http://blogs.msdn.com/b/ieinternals/archive/2011/08/19/understanding-the-impact-of-redirect-response-status-codes-on-http-methods-like-head-get-post-and-delete.aspx
> Ich werde das alles noch mal versuchen stärker einzugrenzen. JS raus,
> POST raus und mal mit GET testen usw.
--
Grüße
Holger Jeromin
W. Wolf
Dec 13, 2011, 9:02:53 AM12/13/11
to
Am 13.12.2011 14:35, schrieb W. Wolf:
>
> Melde mich, wenn ich mehr habe. Hatte halt so ein bisschen auf eine
> Antwort wie "Ach ja, das kennen wir, das liegt an..." gehofft. Macht
> nichts, die Anregungen hier helfen mir schon mal weiter. Danke!
>
Ach ja, gerade noch aufgefallen:
>
> Melde mich, wenn ich mehr habe. Hatte halt so ein bisschen auf eine
> Antwort wie "Ach ja, das kennen wir, das liegt an..." gehofft. Macht
> nichts, die Anregungen hier helfen mir schon mal weiter. Danke!
>
ein Reload der Seite (F5), auch bei gelöschten Cache, verläuft ganz normal.
Schönen Gruß
W. Wolf
Arno Welzel
Dec 14, 2011, 1:34:22 AM12/14/11
to
W. Wolf, 2011-12-13 14:35:
> Am 13.12.2011 13:59, schrieb Martin Honnen:
> [...]
>>
>> Das sieht soweit in Ordnung aus. Sendet der Server eventuelle HTTP
>> header, die dem widersprechen (also etwa Content-Type:
>> application/xhtml+xml oder eventuell zumindest einen anderen
>> charset-Parameter)? Darauf könnte die Fehlermeldung "Neustart des
>> Preparsers ..." hindeuten.
>>
>>
>
> Firebug zeigt mir:
>
> für die standard.css
> Content-Type text/css
> für die js:
> Content-Type application/x-javascript
Das sollte aber text/javascript oder application/javascript stehen und
das mag auch der Grund sein, wieso der IE damit Probleme hat.
Siehe auch:
<http://www.rfc-editor.org/rfc/rfc4329.txt>
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
> Am 13.12.2011 13:59, schrieb Martin Honnen:
> [...]
>>
>> Das sieht soweit in Ordnung aus. Sendet der Server eventuelle HTTP
>> header, die dem widersprechen (also etwa Content-Type:
>> application/xhtml+xml oder eventuell zumindest einen anderen
>> charset-Parameter)? Darauf könnte die Fehlermeldung "Neustart des
>> Preparsers ..." hindeuten.
>>
>>
>
> Firebug zeigt mir:
>
> für die standard.css
> Content-Type text/css
> für die js:
> Content-Type application/x-javascript
das mag auch der Grund sein, wieso der IE damit Probleme hat.
Siehe auch:
<http://www.rfc-editor.org/rfc/rfc4329.txt>
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
W. Wolf
Dec 14, 2011, 3:27:17 AM12/14/11
to
Am 14.12.2011 07:34, schrieb Arno Welzel:
> W. Wolf, 2011-12-13 14:35:
>
>>
> W. Wolf, 2011-12-13 14:35:
>
>>
>> Firebug zeigt mir:
>>
>> für die standard.css
>> Content-Type text/css
>> für die js:
>> Content-Type application/x-javascript
>
> Das sollte aber text/javascript oder application/javascript stehen und
> das mag auch der Grund sein, wieso der IE damit Probleme hat.
>
> Siehe auch:
> <http://www.rfc-editor.org/rfc/rfc4329.txt>
>
Das habe ich nun am Server geändert, ändert aber leider nichts am
>>
>> für die standard.css
>> Content-Type text/css
>> für die js:
>> Content-Type application/x-javascript
>
> Das sollte aber text/javascript oder application/javascript stehen und
> das mag auch der Grund sein, wieso der IE damit Probleme hat.
>
> Siehe auch:
> <http://www.rfc-editor.org/rfc/rfc4329.txt>
>
Verhalten. Neu ist hingegen:
Wenn ich die Reihenfolge der Verweise im HTML-Code ändere passiert
folgendes:
zuerst CSS, danach JS:
es kommt zu den beschriebenen Aussetzern, die beiden Dateien werden wie
beschrieben ein zweites mal vom Server angefordert (StatusCode 200)
zuerst JS, danach CSS:
die Aussetzer sind nicht mehr spürbar, sind aber noch im Debugger
sichtbar. Die beiden Dateien werden jetzt aus dem Browser-Cache
(StatusCode 304) geholt.
Einen Fehler in JS kann ich inzwischen ausschließen. Damit wäre die
Sache in dieser NG wohl erledigt. Wenn jemand dennoch eine neue Idee
habe sollte, so freue ich mich darüber.
Möchte mich daher auch bei allen bedanken die sich beteiligt oder mit
gelesen haben. Sollte ich eine Lösung finden, dann melde ich mich hier
noch mal kurz. (an dem Blog-Link von Holger bin ich noch dran)
Schönen Gruß
W. Wolf
Thomas 'PointedEars' Lahn
Dec 14, 2011, 1:06:09 PM12/14/11
to
W. Wolf wrote:
^^^^^^^
Bitte trag an dieser Stelle Deinen vollständigen/richtigen Namen ein. Das
gilt hier im deutschsprachigen Usenet als höflich und erhöht somit Deine
Chancen auf sinnvolle Antworten. [psf 7.16]
> Am 13.12.2011 13:59, schrieb Martin Honnen:
> [...]
>> Das sieht soweit in Ordnung aus. Sendet der Server eventuelle HTTP
>> header, die dem widersprechen (also etwa Content-Type:
>> application/xhtml+xml oder eventuell zumindest einen anderen
>> charset-Parameter)? Darauf könnte die Fehlermeldung "Neustart des
>> Preparsers ..." hindeuten.
>
> Firebug zeigt mir:
>
> für die standard.css
> Content-Type text/css
Das ist korrekt.
> für die js:
> Content-Type application/x-javascript
Ein korrekter Medientyp ist application/javascript. Der kompatibelste Typ
ist natürlich text/javascript.
<http://PointedEars.de/scripts/test/mime-types/ >
PointedEars
--
apprentice.c - parses /etc/magic to learn magic
(from the file-3.40 README)
^^^^^^^
Bitte trag an dieser Stelle Deinen vollständigen/richtigen Namen ein. Das
gilt hier im deutschsprachigen Usenet als höflich und erhöht somit Deine
Chancen auf sinnvolle Antworten. [psf 7.16]
> Am 13.12.2011 13:59, schrieb Martin Honnen:
> [...]
>> Das sieht soweit in Ordnung aus. Sendet der Server eventuelle HTTP
>> header, die dem widersprechen (also etwa Content-Type:
>> application/xhtml+xml oder eventuell zumindest einen anderen
>> charset-Parameter)? Darauf könnte die Fehlermeldung "Neustart des
>> Preparsers ..." hindeuten.
>
> Firebug zeigt mir:
>
> für die standard.css
> Content-Type text/css
> für die js:
> Content-Type application/x-javascript
ist natürlich text/javascript.
<http://PointedEars.de/scripts/test/mime-types/ >
PointedEars
--
apprentice.c - parses /etc/magic to learn magic
(from the file-3.40 README)
W. Wolf
Dec 15, 2011, 5:05:21 AM12/15/11
to
Am 14.12.2011 19:06, schrieb Thomas 'PointedEars' Lahn:
> W. Wolf wrote:
> ^^^^^^^
> Bitte trag an dieser Stelle Deinen vollständigen/richtigen Namen ein. Das
> gilt hier im deutschsprachigen Usenet als höflich und erhöht somit Deine
> Chancen auf sinnvolle Antworten. [psf 7.16]
Ohne eine Grundsatzdiskussion anfangen zu wollen: Jeder von uns hat halt
> W. Wolf wrote:
> ^^^^^^^
> Bitte trag an dieser Stelle Deinen vollständigen/richtigen Namen ein. Das
> gilt hier im deutschsprachigen Usenet als höflich und erhöht somit Deine
> Chancen auf sinnvolle Antworten. [psf 7.16]
so seine Macken. Ich unterschreibe mich elektronisch seit BTX, also seit
ca. 20 Jahren mit W. Wolf und fast genauso lange im Usenet und noch
viel, viel länger mit gleichem Muster analog. Das werde ich kaum mehr
ablegen wollen und können. Mir ist damit auch bewusst, dass ich von Dir
eventuell keine Antworten mehr bekomme, damit muss ich halt leben. Für
die empfundene Unhöflichkeit entschuldige ich mich. Mich persönlich
stören keine Abkürzungen (oder Zusätze) im Namen, ich unterhalte mich
(immer sehr höflich) mit den Menschen die dahinter stehen und nicht mit
deren Geburtsurkunden. Ich schäme mich auch nicht mit meinen Vornamen,
der Wolfgang lautet, aber du darfst mich auch Wunibald oder Waltraud
nennen, das W. gibt es schließlich her ;-)
Nichts für ungut...
[...]
>
> Ein korrekter Medientyp ist application/javascript. Der kompatibelste Typ
> ist natürlich text/javascript.
>
Verbesserung gebracht. Der Tipp war aber sicher nicht falsch, die
IE-Meldung deutet in der Tat auf so was. Ich bin dran und gebe hier mein
Feedback wenn ich was raus bekomme. Scheint ein exotisches Problem zu sein.
Schönen Gruß
W. Wolf
0 new messages