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)?
> 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">
> 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).
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>
> 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 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?
Am 13.12.2011 13:11, schrieb Thomas 'PointedEars' Lahn:
> 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
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.
> 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.
> 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?
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.
> 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
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!
> 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 Unterschied zwischen 6 bis 10 beschrieben wird:
> 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:
ein Reload der Seite (F5), auch bei gelöschten Cache, verläuft ganz normal.
> 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.
Das habe ich nun am Server geändert, ändert aber leider nichts am
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)
^^^^^^^
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.
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
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.
Wie gestern bereits geschrieben, hatte diese Korrektur leider keine
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.
