Недопустимое состояние отображения для ScriptResource.axd?

Я анализировал данные, которые я собирал, и я сделал несколько выводов. Я заметил, что значительное большинство ошибок, которые я получал, происходит из компьютеров Windows Vista рабочий IE 8 или Firefox 3. Там, где также несколько случаев, где это была Vista и IE 7. Это могло объяснить, почему ошибки теперь просто становятся проблемой, поскольку все больше людей использует новую операционную систему.

Mozilla/4.0 (совместимый; MSIE 8.0; Windows NT 5.1; трайдент/4.0; FunWebProducts; СБРОС.NET 01.01.4322;.NET CLR 2.0.50727) Mozilla/4.0 (совместимый; MSIE 8.0; Windows NT 5.1; трайдент/4.0; GoogleT5; Оптимизированная MSN; CA; Оптимизированная MSN; CA) Mozilla/4.0 (совместимый; MSIE 8.0; Windows NT 6.0; WOW64; трайдент/4.0; GTB5; SLCC1; СБРОС.NET 2.0.50727; СБРОС.NET 3.0.04506; медиацентр ПК 5.0)

Но так или иначе заключение, что я хочу достигнуть, состоит в том, что на основе этой информации я начал изучать, как браузеры обрабатывают сценарии Java и если было что-либо новое, которое могло бы вызывать эту проблему, именно тогда что-то интересное, всплывающее во мне, я нашел на w3School веб-сайте статью о различии в HTML по сравнению с xhtml.

Различия между HTML и HTML 4 XHTML и соглашением о XHTML, отличающимся с содержанием в сценариях:

В HTML 4 тип контента объявляется как CDATA, что означает, что объекты не будут проанализированы. В XHTML тип контента объявляется как (#PCDATA), что означает, что объекты будут проанализированы. Это означает, что в XHTML, все специальные символы должны быть закодированы, или все содержание должно быть перенесено в разделе CDATA.

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

Таким образом, я сразу смотрел в свой код, и я видел, что директива DOCTYPE пропускала на некоторых моих страницах sameones, которые вызывают Проблему. Я также заметил, что, где я производил JavaScript с помощью стандартной программы Клиентского сценария Регистра.NET, это перенесет внутреннее содержание тегов script с атрибутом CDATA, в то время как, где был регулярный JavaScript, записанный на странице не было никакой используемой CDATA. Например,

Я не эксперт по тому, как рендеринг браузера или анализирует возврат HTML, но я сильно полагаю, что он имеет некоторую вещь сделать с ситуацией выше, потому что параметр URL в Ресурсе Сценария запрашивает каждый раз, когда он отказывает, всегда содержит код промежуточные теги script, которые это ниже его. Несколько раз существует даже код таблицы стилей HTML, который может быть найден там также. Например,

http://braun.factoryoutletstore.com/ScriptResource.axd?d=70kBR-jPBTx9R89FxObjhipHPS9CMlta5W6ZZiqkaa5zNOXUU4DtsY8V_8function runSearchForField (eventObj, идентификатор) {если ((eventObj.which == 13) || (eventObj.keyCode == 13)) {var cat_gallery = getParam ('галерея'); кошка var = getParam ('кошка') var searchTerm = Escape (document.getElementById (идентификатор) .value);//должен использовать Escape () функция к urlencode критерию поиска для предотвращения проблем с '&' и '=' URL var символов; если (cat_

http://braun.factoryoutletstore.com/ScriptResource.axd?d=9vS7Hk65j_0hD8to_aPDj

Теперь то, что думает, - то, что некоторые, как, потому что не указываю DOCTYPE на странице, браузер мог бы пытаться вывести на основе данных свое получение затем, он заканчивает тем, что портил, потому что иногда существует CDATA и существуют времена, когда нет никакого CDATA, существующего на странице. Я не знаю действительно, если это - твердая причина предположения, как они говорят что предположения как опасные. Если кто-либо может заштриховать некоторый свет на моей теории и сообщить мне, анализируют ли браузеры xhtml по-другому, что более старая версия или даже если у них были любые аналогичные ситуации.

Хорошо, добро пожаловать в живущий ад, который является MS ajax.

этот бит интересен

Требуемый URL: http://garmn.factoryoutletstore.com/ScriptResource.axd?d=y9_dUwBeGqLlRpT5Dml1zhoQvfa7NKdj69EYuV771kzSsa5KOOXBfJZjk, если (cat_gallery! = Сообщение: Недопустимое состояние отображения

это, "если (cat_gallery! =" вид взглядов неуместных. Я посмотрел бы на JavaScript вокруг что, если и видят, существует ли что-нибудь, что выглядит подозрительным

Принятие Вас использует панели обновления, которые укусили о недопустимом состоянии отображения, приводит меня думать, что состояние отображения получает borked между частичными запросами. Мое предположение (не на основе факта, больше на опыте и боли) - то, что это - одна из двух вещей; любой у Вас есть несколько панелей и состояния, добирается в неисправном состоянии (состояние обновлений панели 1, огни панели 2 прямо после, и не берет изменения), или что это - связанный жизненный цикл страницы (я видел, что несколько привязок данных вызывают недопустимое состояние отображения в частичных обратных передачах страницы),

Я сказал бы, что первая вещь состоит в том, чтобы попытаться воспроизвести ошибку. Перейдите к странице, что это происходит на, и попробуйте каждую комбинацию поведения, о котором можно думать. После того как Вы имеете восстанавливаемую ошибку, присоединяете отладчик и помещаете точки останова на всем протяжении, затем просто ступаете в течение жизненного цикла страницы и видите, существуют ли какие-либо пути выполнения кода, блуждающие в направлениях, Вы не ожидали.

Так или иначе Ajax MS является чрезвычайно черным-boxish, настолько отлаживающие вопросы вокруг этого могут быть мучительно сложными (провел приблизительно 20 часов, делая то, что я просто рекомендовал Вам на прошлой неделе), я желаю Вам всего наилучшего и действительно надеюсь, что это помогает Вам вниз правильный путь.

Это могло бы быть немым ответом, но Вы проверили свой менеджер состояния сеанса? значение по умолчанию находится В PROC, который не работает с веб-фермой, необходимо использовать SQL или некоторого другого менеджера состояния.

Эти ошибки имеют тенденцию происходить при хостинге сайта на кластере выравнивания нагрузки или в веб-ферме. При развертывании приложения в той среде необходимо удостовериться, чтобы конфигурационные файлы на каждом сервере совместно использовали то же значение для validationKey и decryptionKey, которые используются для хеширования и дешифрования соответственно. Это требуется, потому что Вы не можете гарантировать, какой сервер обработает последовательные запросы.

С вручную сгенерированными значениями ключа настройки должны быть подобны следующему примеру. Удостоверьтесь, что элемент является нижним разделом в web.config файле.

<machineKey validationKey="0BE61B38B9836B541C45728ADB9D93A6FD819169DBB6AD20078A70F474650CC0295C69131E083A6B3762C457BBAF3E66E18F294FDA434B9DD6758631A90A2E20" decryptionKey="B80CC12266B36CCF35EF0708DB5854EDA3BBEBA1A7C89A4E" validation="SHA1"/>

Вот изящный небольшой ключевой генератор, который можно использовать для генерации значений ключа - http://www.eggheadcafe.com/articles/GenerateMachineKey/GenerateMachineKey.aspx

Таким образом, как Вы, возможно, предположили, d параметр в ScriptResource.axd является на самом деле ключом расшифровки, и когда тот ключ не будет соответствовать предыдущему запросу, платформа.NET бросит недопустимую ошибку состояния отображения.

Надежда, которая помогает!

Эй Матовый Большое спасибо для Вас Справка. Хорошо это - то, что у меня есть Уведомление в моем анализе, этот Запрос, кажется, всегда переплетается с тем же кодом JavaScript, я включал строку из своего журнала ошибок, который показывает требуемый URL, который вызвал проблему.

/ScriptResource.axd?d=70kBR-jPBTx9R89FxObjhipHPS9CMlta5StoreUrl'%20is%20already%20set.%20*/function%20runSearchForField(eventObj,%20id){%20%20%20%20if%20((eventObj.which%20==%2013)%20||%20(eventObj.keyCode%20==%2013))%20%20%20%20%20{%20%20%20%20%20%20%20%20var%20cat_gallery%20=%20%20getParam('gallery');%20%20%20%20%20%20%20%20var%20cat%20=%20getParam('cat')%20%20%20%20%20%20%20%20var%20searchTerm%20=%20escape(document.getElementById(id).value);%20//%20must%20use%20escape()%20function%20to%20urlencode%20search%20term%20to%20avoid%20issues%20with%20'&'%20and%20'='%20symbols%20%20%20%20%20%20%20%20var%20url;%20%20%20%20%20%20%20%20%20%20%20%20if%20(cat_gallery%20!=

поскольку Вы видите, что "d" параметр повреждается. Что происходит, вот то, что Система. Сеть. UI.Page. DecryptString бросит Недопустимую ошибку состояния отображения, когда он попытается дешифровать эту строку. То, что я хотел бы знать, - то, как может эта строка становиться поврежденным. Я смотрел на JavaScript, и все кажется хорошо мне, единственная нечетная вещь состоит в том, что существуют некоторые комментарии в коде, который является комментарием с/*, чтобы обозначить, что строка является просто комментариями. Я не использую Вложенные панели, но я делаю у меня есть одна панель обновления на странице.

Мы испытали то же самое, и похоже, что это связано с ошибкой в ​​механизме рендеринга IE8.

Взгляните на следующие ресурсы: http://blogs.msdn.com/ieinternals/archive/2009/07/27/Bugs-in-the-IE8-Lookahead-Downloader.aspx http://connect.microsoft.com/IE /feedback/ViewFeedback.aspx?FeedbackID=467062

В основном на странице есть несколько тегов, которые вызывают «перезапуск парсера», что приводит к пропуску 4К HTML на странице. Это означает, что браузер помещает HTML в ScriptResource.axd, который появляется на 4096 байт позже на странице.

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

Ошибка IE8

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

См. это обсуждение здесь: Ошибка IE8 - отброшен 4K - «Недопустимое состояние просмотра» при загрузке ScriptResource.axd

... в частности, обновление EricLaw-MSFT, когда он говорит:

Стоит упомянуть, что любой, кто сталкивается с проблемой здесь, в IE6 / IE7 или Firefox, сталкивается с другой проблемой, не связанной на проблему IE8, описанную ниже.

См. также Ошибки в IE8 's Lookahead Downloader

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

Обновить : По состоянию на 01 апреля 2010 г. эти ошибки IE8 были исправлены с помощью накопительного обновления IE8 (KB980182).
Это сообщение: Исправлен загрузчик IE8 Lookahead дает более подробную информацию об ошибках и других возможных обходных решениях, кроме ожидания, пока все в мире загрузят исправление.

Другие браузеры

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

Веб-фермы

Эта проблема не ограничивается сайтами, работающими на веб-фермах, но если вы используете ферму, ознакомьтесь с здесь ответ от jesal который может помочь