IE 8 удаляет страницы памяти?

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

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

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

<a href="myValidLink.aspx">Here 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, имеет проблему и оставляет некоторые страницы памяти (4k) в некоторых условиях.

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

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

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

  • Кто-нибудь еще столкнулся с этим? (может быть, теперь это на вашем радаре?)
  • Можно ли последовательно реплицировать эту проблему?
  • Любые идеи о том, что это такое? Можете ли вы проверить или опровергнуть мою теорию?
  • Есть ли какие-либо исправления или обходные пути?

Ответы

Ответ 1

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

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

- = Impact = -

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

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

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

- = Обход = -

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

Итак, вместо размещения

[META HTTP-EQUIV = "Content-Type" CONTENT = "text/html; charset = utf-8" ]

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

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

12331 hits to ScriptResource & WebResource / 183 errors

Сломанная информация useragent. Кажется, поддерживает только теорию 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>