Недействительные параметры Webresource.axd

Оригинальный вопрос:

Мы имеем нечетную ошибку при генерации URL-адреса WebResource.axd. (Похоже, что это не связано с довольно распространенной ошибкой "Исправление WebRsource.axd Padding недопустимо и не может быть удалено".

У нас есть веб-страница ASP.NET, которая при создании добавляет ссылку script на 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 является чем-то иным, чем веб-ресурс, который автоматически включается .NET, когда определенные функции включены на странице... в этом случае - валидатор поля. Взгляд на содержимое фактического WebResource.axd показывает очень стандартный набор функций Javascript, которые, как представляется, предназначены для обработки общих событий .NET. Не то, что мы создали.

Кто-нибудь видел что-нибудь подобное? (или, лучше, кто-нибудь понял, почему это происходит, и придумайте способ его устранения?)

EDIT 0: Дополнительная информация:

Пункт 1: В ответ на один ответ мы убедились, что наши скрипты заключены в рамки с тегами CDATA, так как наш doctype является xhtml переходным:

<!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 байт данных).

Ответ 2

в соответствии с этим сообщением:

http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv

Похоже, что проблема связана с тем, как браузеры визуализируют страницы по-разному, когда doctype не указан.

Вот еще один интересный пост, который я нашел на эту тему, но не решение:

http://blog.aproductofsociety.org/?p=11

на приведенной выше странице у него есть "Response.Cache.SetNoStore()" как возможное решение в комментариях, я попробую это, чтобы увидеть, помогает ли это.

Ответ 3

Microsoft ответила на эту проблему:

Примечание - ошибка в Internet Explorer 8. Команда Internet Explorer изучает эту проблему.

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

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

- = Workaround = - Следовательно, в настоящее время мы полагаем, что эта проблема может быть уменьшена путем объявления 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.

ПРИМЕЧАНИЕ. Появились сообщения о том, что эта проблема все еще происходит, когда META HTTP-EQUIV отсутствует на странице. Мы уточним этот комментарий, когда у нас будет больше расследований.  Отправлено Microsoft от 30.06.2009 в 12:25

Ответ 4

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

Ответ 5

Какую версию .NET вы компилируете? Что произойдет, если вы измените сборку для сборки для более старой или более новой версии? (не уверен, что это сделает что-нибудь, но стоит попробовать)

Если это все еще происходит, я думаю, вы должны сообщить об ошибке на Microsoft Connect. Они должны вернуться к вам довольно быстро.

Ответ 6

У вас есть какие-либо HttpHandlers или модули, зарегистрированные в веб-конфигурации, которые изменяют отображаемый HTML до его отправки пользователю?

Часто это может быть:

  • Minifiying JS и CSS
  • Убедитесь, что HTML действительно

Возможно, стоит посмотреть.