IE 8 сбрасывает страницы памяти? - PullRequest
25 голосов
/ 07 мая 2009

Этот вопрос является побочным результатом / эволюцией этого вопроса . (Этот вопрос был помечен как решенный, потому что я назначил ему награду, и он автоматически разрешился, но так и не получил ответа.)

Резюме таково: у нас есть сайт ASP.NET. Иногда мы получаем ошибки, когда клиент запрашивает причудливые URL. Из ресурсов, которые запрашивает клиент, похоже, что в html-источнике отсутствует блок текста размером 4 КБ.

Простой пример ... если у нас есть страница, которая выглядит следующим образом:

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

Клиент может запросить URL: «myValidLiORE% 20STUFF% 20LATER».

Он действует так, как если бы раздела исходного html просто не было ... и этот отсутствующий раздел, кажется, имеет длину 4 КБ (4096 байт) (или, по мнению некоторых людей, иногда 1 КБ?).

К сожалению, мы не можем воспроизвести эту ошибку по требованию, хотя мы видим, что она приходит от клиентов много раз в день.

Сначала мы думали, что это проблема с Webresource.axd, потому что мы часто видели его там ... но теперь я думаю, что это произошло главным образом потому, что мы группировали похожие ошибки, и эти ошибки имели место, когда коррупция произошла в этой конкретной области. Теперь, когда я смотрю на более широкий круг проблем, я вижу места, где мы получаем совершенно разные ошибки, которые выглядят так, как будто они вызваны одной и той же проблемой выпадения фрагмента.

Мы много видели это в IE 8, и это стало более частым, так как IE 8 стал более распространенным. Иногда мы видим это в браузере, который сообщает о себе как IE 7 ... что будет делать IE 8, если он переведен в «режим совместимости».

Моя теория, на данный момент (которую я пытаюсь найти способ проверить) заключается в том, что веб-сервер правильно отправляет все данные в потоке байтов ... и что браузер, IE 8, возникла проблема, при некоторых условиях он сбрасывает страницу памяти (4 КБ).

Однако я немного обеспокоен этой теорией, так как, по-видимому, некоторые люди сообщали, что видели это "иногда" в IE 6 или FF 3 ... они обычно являются выбросами и могут быть просто разными проблемами с похожими симптомами. , но если это действительно то же самое в тех браузерах, это разрушило бы мою теорию. Тем не менее, у меня нет лучшей идеи на данный момент.

Еще одна идея, которая у меня возникла, - это, возможно, относительно недавний пакет обновления для сервера, который вызывает проблемы с данными, передаваемыми клиентам, и иногда теряет 4 КБ. Проблема этой теории заключается в том, что она не объясняет большой перевес ошибок в IE 8 и их отсутствие в других клиентских браузерах.

Итак, на вопросы, на которые, надеюсь, в конечном итоге будут даны ответы:

  1. Кто-нибудь еще сталкивался с этим? (может теперь, когда он у тебя на радаре?)
  2. Кто-нибудь может повторить эту проблему последовательно?
  3. Есть идеи, что это? Можете ли вы подтвердить или опровергнуть мою теорию?
  4. Есть ли исправления или обходные пути?

Ответы [ 4 ]

12 голосов
/ 26 июня 2009

** Изменить 4/1/10: ** Обновление: ошибка 4k теперь исправлена ​​накопительным обновлением IE8 от 30.03.2010. blogs.msdn.com/ieinternals/archive/2010/04/01/

Команда Internet Explorer расследует эту проблему.

- = Impact = -

Пока что мы считаем, что проблема не влияет на работу конечного пользователя с веб-приложением; единственный отрицательный эффект - ложные / неправильно сформированные запросы, отправленные механизмом спекулятивной загрузки JavaScript. Когда скрипт действительно нужен анализатору, он будет правильно загружен и использован в это время.

- = = обстоятельства -

Похоже, что ложный запрос возникает только в определенных временных ситуациях, только когда принудительный перезапуск принудительно перезапускается (например, когда в документе появляется тег META HTTP-EQUIV, содержащий Content-Type с директивой CHARSET), и только когда URL SRC JavaScript занимает 4096-й байт тела ответа HTTP.

- = Обход = -

В настоящее время мы считаем, что эту проблему обычно можно решить, объявив CHARSET страницы с помощью заголовка HTTP Content-Type, а не указав его на странице.

Итак, вместо того, чтобы ставить

[META HTTP-EQUIV = "Тип контента" CONTENT = "text / html; charset = utf-8"]

Вместо этого отправьте в заголовок вашего заголовка следующий HTTP-заголовок ответа:

Content-Type: text / html; кодировка = UTF-8

Обратите внимание, что спецификация кодировки в заголовке HTTP приводит к повышению производительности во всех браузерах, поскольку синтаксическим анализаторам браузера не нужно перезапускать синтаксический анализ с самого начала при обнаружении объявления набора символов. Кроме того, использование заголовка HTTP помогает смягчить некоторые векторы атак XSS.

2 голосов
/ 01 сентября 2009

http://blogs.msdn.com/ieinternals/archive/2009/07/27/Bugs-in-the-IE8-Lookahead-Downloader.aspx является текущим сообщением по этому вопросу.

Недостающая ошибка 4k: В статье говорится: «Объявляя CHARSET страницы, используя заголовок HTTP Content-Type, а не указав его на странице, вы можете устранить одну причину перезапусков парсера». Эрик Лоуренс в электронном письме: «К сожалению, еще одной известной причиной перезапуска анализатора является использование пространств имен XML, которые, по-видимому, использует ваш сайт». Так что если вы используете XHTML, проблема 4K может возникнуть!

0 голосов
/ 29 октября 2009

FWIW Вот статистика, которую я получил за 1 месяц журналов в LogParser.

12331 hits to ScriptResource & WebResource / 183 errors

Разбит по информации об агентах. Кажется, поддерживает только теорию IE8 (плюс пользовательские агенты «режима совместимости»).

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

Одиночная ошибка, отличная от IE8, вообще не имеет строки запроса, поступающей из браузера Firefox / 3.5.3 (должна быть не связана).

У меня нет META HTTP-EQUIV = "Content-Type" на моих страницах. Хотя у меня действительно есть это, чтобы отскочить не-Javascript пользователей.

<noscript>
    <meta http-equiv=Refresh content="0; URL=/ErrorPage.aspx?Error=NoJavascript">
</noscript>
0 голосов
/ 21 сентября 2009

У нас та же проблема. Я добавляю:

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

в наш базовый класс страниц. Я сообщу о результатах в ближайшее время.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...