Я могу вспомнить три причины, только одна из которых на самом деле указывает на настоящую ошибку как таковую:
Кто-то пытается использовать дыру в безопасности в asp.net (патч здесь ), где вы можете получить один из обработчиков axd для обслуживания любого контента на веб-сервере, если сможете определить ключ шифрования.Это маловероятно, но возможно.В этом случае вам не нужно ничего делать, кроме как убедиться, что вы применили это исправление.
(это то, что я заметил на сайте, который только что закончил)Сценарий - это когда существующий сайт был заменен или веб-сервер был изменен по сравнению с тем, что было ранее.Если у вас есть общедоступный сайт и в Google, скажем, люди могут часто просматривать «кэшированную» страницу, если они пытаются получить старый контент или даже если текущая страница не соответствует ожиданиям (возможно, ошибка или даже просторазные).Проблема в том, что если сайт использует webresource.axd, на этой странице будет ссылка на него.Браузер открывает кешированный HTML и затем делает запрос.Если сайт имеет , был изменен или является заменой, тогда старые ссылки axd могут быть недействительными и приведут к ошибке.
Если это сайт mvc, вы больше не будетеиспользуя ресурсы, предоставляемые axds, и в этом случае вы можете рассмотреть возможность их удаления с сайта, отредактировав веб-конфигурацию и добавив для них записи «remove» в разделе обработчиков system.webserver.Тогда запросы будут давать 404, и вы больше не будете получать ошибки.Точно так же, если сайт действительно использует axds на законных основаниях, но вы не можете самостоятельно воспроизвести ошибки, просматривая его, то вам, вероятно, не о чем беспокоиться.
, на котором работает сайтследовательно, веб-ферма и каждая машина должны иметь один и тот же ключ компьютера, это действительно нужно внимание, если это так.Я оставил это до последнего, хотя, потому что, глядя на другие ваши вопросы, я предполагаю, что веб-ферма не участвует:)
Мне бы хотелось отформатировать этот ответ лучше, но яна моем телефоне, извинения!