IE 8 upuszczając strony pamięci?

Question

To pytanie jest spin-off/ewolucji this question. (To pytanie zostało oznaczone jako rozwiązane, ponieważ ustawiłem na nim nagrodę i zostało automatycznie rozwiązane, ale nigdy tak naprawdę nie otrzymałem odpowiedzi.)

Podsumowując: mamy witrynę ASP.NET. Czasami pojawiają się błędy, gdy klient prosi o dziwne adresy URL. Z zasobów, o które pyta klient, wygląda na to, że brakuje kodu 4k tekstu ze źródła html.

Prosty przykład ... jeśli mamy stronę, która wygląda tak:

<a href="myValidLink.aspx">Here's some text</a> 
a bunch more stuff 
...(a large block of text)... 
AND NOW MORE STUFF LATER 

Klient może poprosić o adres URL: "myValidLiORE% 20STUFF% 20LATER".

Zachowuje się tak, jakby fragment źródła html po prostu nie istniał ... a sekcja, której brakuje, wydaje się mieć dokładnie 4KB (4096 bajtów) długości (lub według niektórych osób, czasami 1KB?).

Niestety, nie możemy powtórzyć tego błędu na żądanie, chociaż widzimy, że przychodzi on od klientów wiele razy dziennie.

Początkowo myśleliśmy, że to był problem z Webresource.axd, ponieważ zdarzyło się, że widzieliśmy to bardzo często ... ale teraz myślę, że to głównie dlatego, że grupowaliśmy podobne błędy razem i te błędy miały tendencję do występowania kiedy doszło do korupcji w tym konkretnym obszarze. Teraz, gdy patrzę na szerszy zakres problemów, widzę miejsca, w których dostaję bardzo różne błędy, które wyglądają, jakby były spowodowane przez ten sam problem z porzuceniem kawałka.

Widzieliśmy to bardzo często w IE 8, i stało się częstsze, ponieważ IE 8 stał się bardziej powszechny. Widzimy to od czasu do czasu z przeglądarką, która zgłasza się jako IE 7 ... co zrobi IE 8, jeśli zostanie wprowadzona w "tryb zgodności".

Moja teoria, w tym miejscu (którą próbuję znaleźć sposób na przetestowanie) polega na tym, że serwer sieciowy poprawnie wysyła wszystkie dane w strumieniu bajtów ... i że przeglądarka, IE 8 , ma problem i upuszcza stronę pamięci (4k) w pewnych warunkach.

Jestem trochę zaniepokojony tą teorią, ponieważ podobno niektórzy ludzie donoszą, że widzą to "od czasu do czasu" za pomocą IE 6 lub FF 3 ... to zwykle są odstające i mogą być tylko różnymi problemami z podobnymi symptomy, ale jeśli to naprawdę jest to samo w tych przeglądarkach, to wyrzuciłoby moją teorię z wody. W tej chwili nie mam lepszego pomysłu.

Jeszcze jeden pomysł, jaki miałem, to być może stosunkowo niedawny pakiet serwisowy na serwerze, który powoduje problemy z przesyłaniem danych do klientów, zrzucając sporadyczne 4 KB. Problem z tą teorią polega na tym, że nie wyjaśnia ona wielkiej przewagi błędów na IE 8 i ich braku w innych przeglądarkach klienckich.

więc pytania, które mam nadzieję, że w końcu ma odpowiedzi:

1. Czy ktoś napotkał ten? (może teraz, że jest na twoim radarem?)
2. Czy ktoś może powtarzać ten problem konsekwentnie?
3. Jakieś pomysły na to, co to jest? Czy możesz zweryfikować lub obalić moją teorię?
4. Czy są jakieś poprawki lub obejścia?

Answer 1

** Edycja 4/1/10: ** Aktualizacja: błąd 4k jest teraz rozwiązany za pomocą zbiorczej aktualizacji IE8 z 3/30/2010. blogs.msdn.com/ieinternals/archive/2010/04/01/

zespół Internet Explorer został bada ten problem.

- = = Impact -

dotąd, uważamy, że problem ma żadnego wpływu na doświadczenie użytkownika końcowego z aplikacji internetowych; Jedynym negatywnym efektem są fałszywe/zniekształcone żądania wysyłane przez mechanizm spekulatywnego pobierania JavaScript. Kiedy skrypt jest rzeczywiście potrzebny przez analizator składni, zostanie on poprawnie pobrany i użyty w tym czasie.

- = Okoliczności = -

nieprawdziwy-prośba wydaje się występować tylko w niektórych sytuacjach przejściowych, tylko wtedy, gdy wcześniej parser jest zmuszony do ponownego uruchomienia (jak wtedy, gdy znacznik META HTTP-equiv zawierający Content-Type z wyświetloną w dokumencie dokumentem CHARSET) i tylko wtedy, gdy URL SRC JavaScript obejmuje 4096. bajt treści odpowiedzi HTTP.

- = Obejście = -

Aktualnie że ten problem może być zasadniczo złagodzony poprzez uznanie charset strony za pomocą nagłówek HTTP Content-Type raczej niż określenie go w obrębie strony.

Więc zamiast oddanie

[META HTTP-equiv = "Content-Type" content = "text/html; charset = UTF-8"]

w tagu głowy zamiast tego wysłać następujące nagłówka odpowiedzi HTTP:

Content-Type: text/html; charset = utf-8

Należy zauważyć, że specyfikacja zestawu znaków w nagłówku HTTP poprawia wydajność we wszystkich przeglądarkach, ponieważ parsery przeglądarki nie muszą ponownie uruchamiać analizowania od początku po napotkaniu deklaracji zestawu znaków. Ponadto użycie nagłówka HTTP pomaga złagodzić niektóre wektory ataku XSS.

Answer 2

http://blogs.msdn.com/ieinternals/archive/2009/07/27/Bugs-in-the-IE8-Lookahead-Downloader.aspx jest obecny stanowisko w tej sprawie.

Brakujący błąd 4k: Artykuł zawiera: "Deklarując parametr CHARSET strony za pomocą nagłówka HTTP Content-Type zamiast określać go na stronie, można usunąć jedną z przyczyn restartowania analizatora składni." Eric Lawrence w e-mailu: „Niestety, kolejna znana przyczyna restartów parser wykorzystanie przestrzeni nazw XML, który pojawia się we własną stronę, aby użyć” Więc jeśli używasz XHTML, może wystąpić problem 4K!

Answer 3

Mamy ten sam problem. Dodaję:

 Response.ContentType = "text/html" 
     Response.Charset = "utf-8" 

do naszej podstawowej klasy strony. Wkrótce opowiem o wynikach.

Answer 4

FWIW Oto statystyki dostałam od 1 miesiąca dzienników w LogParser.

12331 hits to ScriptResource & WebResource/183 errors

rozbiciu identyfikującego informacji.Wygląda na to, że obsługuje teorię IE8 (plus agenty użytkownika w trybie "zgodności").

 
cs-uri-stem   MSIEVersion TridentVersion COUNT 
/WebResource.axd  MSIE+8.0 Trident/4.0  100 
/ScriptResource.axd MSIE+8.0 Trident/4.0  36 
/WebResource.axd  MSIE+7.0 Trident/4.0  44 
/ScriptResource.axd MSIE+7.0 Trident/4.0  2 
/ScriptResource.axd NOT IE  NOT Trident  1 

Pojedynczy błąd nie IE8 ma ciągu kwerendy w ogóle, pochodzących z Firefox/3.5.3 przeglądarce (musi być niezwiązany).

Nie mam żadnych META HTTP-EQUIV = "Content-Type" na moich stronach. Chociaż mam to, aby odbijać użytkowników spoza Javascript.

<noscript> 
    <meta http-equiv=Refresh content="0; URL=/ErrorPage.aspx?Error=NoJavascript"> 
</noscript>