Ответ 1
В конечном итоге это было исправлено Microsoft:
http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx
Оригинальный вопрос:
Мы имеем нечетную ошибку при генерации 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 байт данных).
В конечном итоге это было исправлено 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
Похоже, что проблема связана с тем, как браузеры визуализируют страницы по-разному, когда doctype не указан.
Вот еще один интересный пост, который я нашел на эту тему, но не решение:
http://blog.aproductofsociety.org/?p=11
на приведенной выше странице у него есть "Response.Cache.SetNoStore()" как возможное решение в комментариях, я попробую это, чтобы увидеть, помогает ли это.
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
Я из команды ASP.NET - мы ищем клиента, который хочет работать с нами над исследованием этой проблемы. Если кто-то может надежно воспроизвести проблему, запросив свои собственные страницы и проверив журналы, и готов работать с нашей группой поддержки, ответьте или отправьте мне прямое сообщение. Спасибо!
Какую версию .NET вы компилируете? Что произойдет, если вы измените сборку для сборки для более старой или более новой версии? (не уверен, что это сделает что-нибудь, но стоит попробовать)
Если это все еще происходит, я думаю, вы должны сообщить об ошибке на Microsoft Connect. Они должны вернуться к вам довольно быстро.
У вас есть какие-либо HttpHandlers или модули, зарегистрированные в веб-конфигурации, которые изменяют отображаемый HTML до его отправки пользователю?
Часто это может быть:
Возможно, стоит посмотреть.
Это старое сообщение... но я столкнулся с поиском в google и напомнил об этом...
http://www.troyhunt.com/2010/09/fear-uncertainty-and-and-padding-oracle.html
Может быть, это было связано?