none
Mehrfache IE9 Requests RRS feed

  • Frage

  • Guten Morgen,

    ich habe diese Frage bereits im IE-Forum laufen, weil ich dachte dass es sich dabei um ein reines IE-Problem handelt. Nun bin ich mir aber nicht mehr so sicher, weil ich das Problem in einer ASP.Net Anwendung auf dem IIS sehe, nicht jedoch unter vergleichbaren Bedingungen auf einer Apache / Tomcat Kombi.

    Es geht um Folgendes:
    Ein Formular (z.B. Anmeldung) wird per Post abgesendet. Auf dem Server findet ein Redirect statt, die neue HTML-Seite beinhaltet neben dem HTML-Code auch Verweise auf zusätzliche Ressourcen (CSS-, JS- und Bilddateien).

    Wenn man sich nun die Netzwerkaufzeichnung im IE9 anschaut (F12, Netzwerk, Aufzeichnung starten), so passieren hier komische Sachen: Die nachzuladenden Ressourcen erscheinen in der Tabelle, der Download wird aber abgebrochen. Die Daten werden vom IE ein zweites mal angefordert und werden erst dann vom Server geliefert (Ergebnis 200). In der Detailansicht ist unter Initiator für die zweiten Downloads ist folgendes zu lesen: „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).“

    Diese Sache ist selbst hier im Forum nach der Anmeldung auf dem Microsoft-Server zu beobachten, der Download der *.css und jquery.min.js werden zunächst abgebrochen, und ein zweites mal mit der Initiator-Meldung von oben, nachgeladen.

    Je nach dem wie schnell der Server antwortet, entsteht durch diesen Ablauf eine spürbare und entsprechend unschöne Verzögerung bei der Anzeige der Seite.

    Weitere Fakten:
    Das Problem tritt nur im IE9-Modus auf. Schaltet man den IE in den IE8 oder IE7-Modus um, dann gibt es diese abgebrochenen Downloads nicht.
    Wenn die Weiterleitungs-Seite direkt aufgerufen wird, ist auch alles normal. Zum Aussetzer kommt es nur nach einen Redirect.
    Mit anderen Browsern konnte ich das nicht reproduzieren.
    So wie es aussieht, ist man im IE-Forum ratlos, zumindest traut sich kaum jemand was dazu zu sagen.

    Schönen Gruß
    W. Wolf

    Montag, 19. Dezember 2011 09:42

Antworten

  • Ich kann das leider auf meinem Windows 2008 R2 aus mir nicht klaren Gründen nicht nachvollziehen, und zwar findet der redirectete Request nicht als POST, sondern als GET statt (obwohl es eigentlich ein POST sein sollte).

    Auf meinem Laptop kann ich es nachvollziehen. Der Parser-Restart erfolgt wegen des X-UA-Compatible Headers "EmulateIE9", denn dieser besagt, sich auf den DOCTYPE zu verlassen und im "almost standards mode" zu rendern. Deswegen findet das auch nur mit IE9 statt.

    Eine Verzögerung kann ich dadurch nicht erkennen. Der *spekulative* Request wird praktisch sofort abgebrochen, völlig unabhängig davon, was der Server macht, HTTPWatch gibt für drei abgebrochene Requests, die gleichzeitig stattfanden ca. 40 ms an. Wenn da eine Verzögerung erfolgt, dann durch die Größe des Dokuments. Alleine der Download der zwei Dokumente in deiner letzten Zeile braucht 200-400 ms. Insgesamt wird ein "Gap" von 6-12 Sekunden bei mir angezeigt, je nach verwendetem Tool.

    Wenn in euren Seiten kein X-UA-Compatible Header vorhanden ist, bezweifle ich, daß dieselbe Situation vorliegt, auch wenn es vielleicht so "aussieht".

    Bei Bedarf bitte in der IE-Gruppe fortsetzen, da es m.E. nichts mit ASP.NET zu tun hat.


    IEFAQ: http://iefaq.info
    • Als Antwort markiert W. Wolf Dienstag, 20. Dezember 2011 15:12
    Dienstag, 20. Dezember 2011 14:16

Alle Antworten

  • Wie schon im IE-Forum gesagt, läßt sich dazu ohne Reproduktionsmöglichkeit nichts sagen. Du erwähnst jetzt, daß es auch hier reproduzierbar ist. Nicht für mich. Du müsstest bitteschön schon eine exakte Reproduktionsanleitung zu geben versuchen. Im übrigen habe ich Probleme, mit F12 hier überhaupt das Login einzufangen. Die Tools verschwinden bei mir nämlich, wenn ich auf sign-in oder sign-out klicke. Ich wundere mich, daß du da überhaupt was capturen konntest. Mit HTTPWatch kann ich das Beschriebene jedenfalls nicht sehen. Kannst du es mit Fiddler2 nachvollziehen? (Damit liesse es sich auch aufzeichnen.)

    Da das Verhalten mit bestimmten Servern auftritt, würde ich mir die Response-Header mal genau anschauen, ob es da Unterschiede gibt, die das erklären. Auch auf die Zone würde ich achten.


    IEFAQ: http://iefaq.info
    Montag, 19. Dezember 2011 18:12
  • Guten Morgen,

    dann will ich es mal versuchen:

    http://social.msdn.microsoft.com/Forums/de-DE/categories im IE aufrufen
    SigIn klicken
    F12 Entwicklertools starten
    In den Entwicklertools:
      Netzwerk aktivieren
      Browsercache löschen
      Aufzeichnung starten
    Zurück zum IE
    Login-Daten eingeben und Anmelden

    In den Entwicklertools wird nun die Tabelle befüllt:

    Das alles kann ich auch mit Fidler reproduzieren. Auf den MSDN-Servern merkt man die Verzögerung kaum, auf meinem vergleichsweise schwachen Server hier im Haus jedoch schon. Das ist schade, weil es nicht sein müsste. Schließlich tritt der "Fehler" nur im IE9 Modus auf. Wie schon beschrieben, schalte ich in den Entwicklertools den Modus auf IE8 oder 7, so ist alles normal. In Ergänzung: Verwende hier W7-64 und der IE meldet sich mit 9.0.8122.16421.

    Schönen Gruß
    W. Wolf

    Dienstag, 20. Dezember 2011 06:54
  • Ich kann das leider auf meinem Windows 2008 R2 aus mir nicht klaren Gründen nicht nachvollziehen, und zwar findet der redirectete Request nicht als POST, sondern als GET statt (obwohl es eigentlich ein POST sein sollte).

    Auf meinem Laptop kann ich es nachvollziehen. Der Parser-Restart erfolgt wegen des X-UA-Compatible Headers "EmulateIE9", denn dieser besagt, sich auf den DOCTYPE zu verlassen und im "almost standards mode" zu rendern. Deswegen findet das auch nur mit IE9 statt.

    Eine Verzögerung kann ich dadurch nicht erkennen. Der *spekulative* Request wird praktisch sofort abgebrochen, völlig unabhängig davon, was der Server macht, HTTPWatch gibt für drei abgebrochene Requests, die gleichzeitig stattfanden ca. 40 ms an. Wenn da eine Verzögerung erfolgt, dann durch die Größe des Dokuments. Alleine der Download der zwei Dokumente in deiner letzten Zeile braucht 200-400 ms. Insgesamt wird ein "Gap" von 6-12 Sekunden bei mir angezeigt, je nach verwendetem Tool.

    Wenn in euren Seiten kein X-UA-Compatible Header vorhanden ist, bezweifle ich, daß dieselbe Situation vorliegt, auch wenn es vielleicht so "aussieht".

    Bei Bedarf bitte in der IE-Gruppe fortsetzen, da es m.E. nichts mit ASP.NET zu tun hat.


    IEFAQ: http://iefaq.info
    • Als Antwort markiert W. Wolf Dienstag, 20. Dezember 2011 15:12
    Dienstag, 20. Dezember 2011 14:16
  • Das sind viele neue Erkentnisse, einiges davon verstehe ich noch nicht, bzw. bin dabei durch weitere Tests näheres zu ergründen. Ich werde, wie vogeschlagen, die IE-Gruppe für weitere Fragen nutzen.

    Nur so viel zu deinen ersten Satz: Könnte das damit zu tun haben?

    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

    Danke Dir für Deine Mühe.

    Schönen Gruß

    W. Wolf

    Dienstag, 20. Dezember 2011 15:12
  • Ja und nein. In dem Artikel wird ausgeführt, daß IE6-10 ein POST 302 mit einem GET verfolgt. Mein 2008 R2 verhält sich danach also "richtig". Die Clients, mit denen wir beide das reproduziert haben (ich nehme an, du auch auf Windows 7) verfolgen aber mit einem POST. Da mein Client auf dem 2008 R2 auch bezüglich der dev tools merkwürdig agiert, denke ich, daß das nicht repräsentativ ist. Und mit dem eigentlichen Phänomen der abgebrochenen Downloads hat es m.E. nicht zu tun.
    IEFAQ: http://iefaq.info
    Dienstag, 20. Dezember 2011 15:32
  • Ok, das war schon klar. Ich hatte den Link ja auch nur in Bezug zu deinen W2008 und den Wechsel von POST zu GET erwähnt.

    Ich kopiere jetzt mal Teile deiner letzten Antwort in das IE-Forum, damit der Faden dort "der Faden nicht reist". Vielleicht klinkt sich da noch jemand ein.

    Schönen Gruß

    W. Wolf

    Mittwoch, 21. Dezember 2011 06:42