Сгенерированы неверные параметры Webresource.axd
Оригинальный вопрос:
У нас странная ошибка при генерации URL WebResource.axd. (Похоже, это не связано с довольно распространенной проблемой "WebRsource.axd Padding недействителен и не может быть удален").
У нас есть веб-страница ASP.NET, которая при создании добавляет ссылку на скрипт в WebResource.axd.
В этом случае мы видим, что ссылка WebResource.axd иногда превращается в мусор после определенного момента, заменяемый тем, что выглядит как javascript. Хуже всего то, что сбой генерации URL кажется несостоятельным.
В нашем случае ссылка должна (и обычно выглядит так):
/WebResource.axd?d=D-wd7RbHCvSp_p0mHAmE4g2&t=633464867255568315
Все хорошо. Тем не менее, мы получаем сообщения об ошибках от пользователей... и URL, к которому они пытаются получить доступ, выглядит (в одном случае):
/WebResource.axd?d=D-wd7RbHCvS/../../images/icons/Ico_resize.gif')}}function%20ShowFilter_Manufacturer(){var%20div.......
[оставшийся кодированный javascript из этой ссылки был удален как нерелевантный]
Еще страннее, мы получили несколько из них в быстрой последовательности от одного и того же пользователя, который, очевидно, пытался перезагрузить страницу... каждый URL немного отличается.
/WebResource.axd?d=D-wd7RbHCvS<garbage>
/WebResource.axd?d=D-wd7RbHCvSp<garbage>
/WebResource.axd?d=D-wd7RbHCvSp_<garbage>
В некоторых случаях мусор кодируется JavaScript, я видел части URL-адреса... полностью пустые строки параметров... Я не вижу очевидного шаблона.
Кроме того, если это уместно, следует отметить, что я не верю, что этот WebResource является чем-то иным, кроме стандартного WebResource, который автоматически включается.NET, когда определенные функции включаются на странице... в этом случае, валидатор поля. Просмотр содержимого реального WebResource.axd показывает очень стандартный набор функций Javascript, которые, похоже, предназначены для обработки общих событий.NET. Не то, что мы создали.
Кто-нибудь видел что-нибудь подобное? (или лучше, кто-нибудь понял, почему это происходит, и придумал способ устранить это?)
РЕДАКТИРОВАТЬ 0: Некоторая дополнительная информация:
Пункт 1: В ответ на один ответ мы убедились, что наши сценарии заключены в теги CDATA, поскольку наш тип документа является xhtml transitional:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
К сожалению, хотя у нас были большие надежды, похоже, проблема не решилась. Мы заметили это чаще всего с IE 8 в качестве браузера, что дало бы некоторую уверенность в том, что это связано с браузером... возможно, то, как браузер анализирует поток... но почему мы получим слегка разные ответы на последующих попытках сбивает с толку меня.
Пункт 2: Оказывается, что пропущенные секции кажутся блоками довольно регулярного размера. Кто-то сообщил, что он видит пропущенные блоки 1k или 4k, и я (пока... пока я только рассмотрел два случая) согласился (в моем случае отсутствовало 4096 байт данных).
7 ответов
В конечном итоге это было исправлено Microsoft:
http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx
Согласно этому посту:
http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv
Похоже, что проблема вызвана тем, что браузеры отображают страницы по-разному, когда тип документа не указан.
Вот еще один интересный пост, который я нашел на эту тему, но до сих пор не нашел решения:
http://blog.aproductofsociety.org/?p=11
на приведенной выше странице в качестве возможного решения в комментариях указано "Response.Cache.SetNoStore()". Далее я попробую это, чтобы посмотреть, поможет ли это.
Microsoft ответила на эту проблему:
Примечание - это ошибка в Internet Explorer 8. Команда Internet Explorer занималась этой проблемой.
- = Impact =- Пока что мы считаем, что проблема не влияет на работу конечного пользователя с веб-приложением; единственный отрицательный эффект - ложные / неправильно сформированные запросы, отправленные механизмом спекулятивной загрузки JavaScript. Когда скрипт действительно нужен парсеру, он будет правильно загружен и использован в это время.
- = Circumstances =- Похоже, что ложный запрос возникает только в определенных временных ситуациях, только когда в документе появляется тег META HTTP-EQUIV, содержащий Content-Type с директивой CHARSET, и только когда URL-адрес JavaScript SRC охватывает 4096-й байт тела ответа HTTP.
- = Обходной путь =- Следовательно, в настоящее время мы считаем, что эту проблему можно устранить, объявив CHARSET страницы, используя заголовок HTTP Content-Type, а не указав его на странице.
Так что вместо того, чтобы ставить
[META HTTP-EQUIV="Тип контента" CONTENT="text/html; charset=utf-8"]
Вместо этого в своем заголовке отправьте следующий HTTP-заголовок ответа:
Content-Type: text / html; кодировка = UTF-8
Обратите внимание, что спецификация charset в заголовке HTTP приводит к повышению производительности во всех браузерах, поскольку синтаксическим анализаторам браузера не нужно перезапускать синтаксический анализ с самого начала при обнаружении объявления набора символов. Кроме того, использование заголовка HTTP помогает смягчить определенные векторы атак XSS.
ПРИМЕЧАНИЕ. Были сообщения, что эта проблема все еще возникает, когда META HTTP-EQUIV нет на странице. Мы будем обновлять этот комментарий, когда у нас будет больше расследований. Написал Microsoft 30.06.2009 в 12:25
Я из команды ASP.NET - мы ищем клиента, готового работать с нами над исследованием этой проблемы. Если кто-то может надежно воспроизвести проблему, запросив собственные страницы и проверив журналы, и желает работать с нашей группой поддержки, пожалуйста, ответьте или отправьте мне прямое сообщение. Спасибо!
С какой версией.NET вы компилируете? Что произойдет, если вы измените свою сборку на более старую или более новую версию? (не уверен, что это что-то сделает, но стоит попробовать)
Если это все еще происходит, я думаю, вы должны опубликовать ошибку об этом в Microsoft Connect. Они должны вернуться к тебе довольно быстро.
Есть ли у вас какие-либо HttpHandlers или модули, зарегистрированные в веб-конфигурации, которые изменяют отображаемый HTML-код перед его отправкой пользователю?
Часто это могут быть:
- Минисификация JS и CSS
- Убедитесь, что HTML верен
Может стоит посмотреть.
Это старый пост... но я наткнулся на поиск в Google и напомнил мне об этом...
http://www.troyhunt.com/2010/09/fear-uncertainty-and-and-padding-oracle.html
Могло ли это быть связано?