Неверное состояние представления для ScriptResource.axd? - PullRequest
11 голосов
/ 26 января 2009

Ресурсы Script Resource и файлы Web Resource периодически вызывают ошибки в моем приложении. Я пытался найти причину проблемы, но безрезультатно. Я замечаю, что переданный параметр «d» в некоторой степени поврежден, и я не могу понять, из-за чего этот параметр поврежден. Я заметил, что JavaScript-код, который в моем приложении каким-то образом переплетается с хеш-кодом, сгенерированным для параметра «d».

Exception genereated on Monday, January 26, 2009, at 2:20 AM
Page location: /ScriptResource.axd?d=y9_dUwBeGqLlRpT5Dml1zhoQvfa7NKdj69EYuV771kzSsa5KOOXBfJZjk%20%20%20%20%20%20%20%20%20%20%20%20if%20(cat_gallery%20!=
Requested Url : http://garmn.factoryoutletstore.com/ScriptResource.axd?d=y9_dUwBeGqLlRpT5Dml1zhoQvfa7NKdj69EYuV771kzSsa5KOOXBfJZjk if (cat_gallery !=
Message: Exception has been thrown by the target of an invocation.
Source: mscorlib
Method: System.Object _InvokeMethodFast(System.Object, System.Object[], System.SignatureStruct ByRef, System.Reflection.MethodAttributes, System.RuntimeTypeHandle)
Stack Trace: at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner) at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks) at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture) at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters) at System.Web.Handlers.ScriptResourceHandler.DecryptString(String s) at System.Web.Handlers.ScriptResourceHandler.DecryptParameter(NameValueCollection queryString) at System.Web.Handlers.ScriptResourceHandler.ProcessRequest(HttpContext context) at System.Web.Handlers.ScriptResourceHandler.System.Web.IHttpHandler.ProcessRequest(HttpContext context) at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Inner Exception: System.Web.HttpException: Invalid viewstate. at System.Web.UI.Page.DecryptStringWithIV(String s, IVType ivType) at System.Web.UI.Page.DecryptString(String s)
User IP: 74.34.62.187

BaseMessage : Exception genereated on Monday, January 26, 2009, at 2:20 AM
Page location: /ScriptResource.axd?d=y9_dUwBeGqLlRpT5Dml1zhoQvfa7NKdj69EYuV771kzSsa5KOOXBfJZjk%20%20%20%20%20%20%20%20%20%20%20%20if%20(cat_gallery%20!=
Requested Url : http://garmn.factoryoutletstore.com/ScriptResource.axd?d=y9_dUwBeGqLlRpT5Dml1zhoQvfa7NKdj69EYuV771kzSsa5KOOXBfJZjk if (cat_gallery !=
Message: Invalid viewstate.
Source: System.Web
Method: System.String DecryptStringWithIV(System.String, System.Web.Configuration.IVType)
Stack Trace: at System.Web.UI.Page.DecryptStringWithIV(String s, IVType ivType) at System.Web.UI.Page.DecryptString(String s)
User IP: 74.34.62.187
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 1.1.4322; Zune 3.0)

Ответы [ 7 ]

5 голосов
/ 03 февраля 2009

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

Mozilla / 4.0 (совместимо; MSIE 8.0; Windows NT 5.1; Trident / 4.0; FunWebProducts; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Mozilla / 4.0 (совместимый; MSIE 8.0; Windows NT 5.1; Trident / 4.0; GoogleT5; MSN Optimized; CA; MSN Optimized; CA) Mozilla / 4.0 (совместимый; MSIE 8.0; Windows NT 6.0; WOW64; Trident / 4.0; GTB5; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; Media Center PC 5.0)

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

Различия между HTML и XHTML HTML 4 и XHTML по-разному работают с содержимым внутри скриптов:

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

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

Итак, я сразу же посмотрел свой код и увидел, что на некоторых моих страницах отсутствует директива DOCTYPE, которые вызывают проблему. Я также заметил, что там, где я выводил JavaScript с помощью подпрограммы .NET Register Client Script, он оборачивал внутреннее содержимое тегов сценария атрибутом CDATA, тогда как там, где был обычный JavaScript, написанный на странице, CDATA не использовался. Например

Функция RunMe () { }

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

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

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

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

4 голосов
/ 23 октября 2009

Мы испытали то же самое, и, похоже, это связано с ошибкой в ​​движке рендеринга 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

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

1 голос
/ 04 ноября 2009

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

IE8 Ошибка

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

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

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

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

См. Также Ошибки в загрузчике Lookahead в IE8

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

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

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

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

Веб-фермы

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

1 голос
/ 26 января 2009

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

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

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

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

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

Надеюсь, это поможет!

1 голос
/ 26 января 2009

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

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

Запрошенный URL: http://garmn.factoryoutletstore.com/ScriptResource.axd?d=y9_dUwBeGqLlRpT5Dml1zhoQvfa7NKdj69EYuV771kzSsa5KOOXBfJZjk if (cat_gallery! = Сообщение: недействительно ViewState

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

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

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

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

0 голосов
/ 28 января 2009

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

0 голосов
/ 26 января 2009

Привет, Мэтт. Большое спасибо за помощь. Хорошо, это то, что я заметил в моем анализе, этот запрос, кажется, всегда переплетается с одним и тем же кодом 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" поврежден. Здесь происходит то, что System.Web.UI.Page.DecryptString выдает ошибку состояния неверного представления при попытке расшифровать эту строку. Я хотел бы знать, как эта строка может стать испорченной. Я посмотрел на JavaScript, и все мне кажется нормальным, единственное, что странно, это то, что в коде есть комментарии с комментарием / *, которые обозначают, что строка - это просто комментарии. Я не использую вложенные панели, но у меня есть одна панель обновления на странице.

...