Можно ли повесить свой обработчик для 400-ой ошибки? К примеру на выдачу моей страницы, вместо стандартной. 400-ая генерится как от безобидного знака "%" - www.sql.ru/%, так и при ошибочном построении запроса (в том же телнете отправляешь случайный набор символов на 80-ый порт и 400 обеспечена).

В идеале должно работать как на facebook.com - при % в урле и всяческих подобных символах - это 404, а неверный запрос - это 400 с выдачей конкретной собственно созданной страницы.

handmadeFromRuТакое пробывали?



Пробовал. Видимо до asp.net запрос не доходит, даже в интегрированном режиме, сразу режется на входе в IIS.

handmadeFromRuхм вообще как раз это на те случаи когда в коде поймать не можеш

Ну 400 это не какая-то там ошибка asp.net (500), это гораздо серьёзнее и судя по всему, до asp.net дело даже не доходит. Ни модули, ни конфиг, ничего не отрабатывает, где-то на входе IIS всё обрабатывается и отсылается клиенту.

spst_st,

у меня получилось только так:




А если не 404, а 400? Знак процента % добавить как по ссылке в первом сообщении в конец урла или по телнету случайный набор символов заслать.

В customErrors пробовал, не работает 400-ая. 404 и 500 без проблем, а 400 не хочет.

В httpErrors не пробовал, так как секция не работает (добавление <error> никак не отражаются на сайте) и её атрибуты не разблокируются, как её включить и разблочить пока не знаю (удаление lockAttributes из applicationHost.config и магическая строка %windir%\System32\inetsrv\appcmd unlock config -section:system.webserver\httperror не помогли, может полностью кампутер перезагрузить надо, а не только вебсервер).

А насчёт 400, нагуглил только - носите свой пропатченый http.sys и подменяйте где надо Внутри него кстати нашёл html с 400-ой и прочими ошибками.

a_titeevА почему в исс то глобальных настройках не поменять? Теоретически, в машин.конфиг она подставит хендлеры и все...

Для 400 не сработало.

Парамон Complete Example for Error Handlers

авторClick this button to create an HTTP 400 (invalid url) error.<br />
Application_Error will catch this

При отладке в студии на стандартном ASP.NET Development Server, 400-ая ошибка ловится, а при запуске с IIS - нет, выбрасывается где-то вначале, сервером, остальные ошибки доходят. Код для проверки целиком взят из приведённой статьи в разделе "Default.aspx". Также 400-ая и в Global.asax (Application_Error.aspx) тоже непопадает.

Парамонst_st,

Тогда, наверно копать в сторону iis хендлера/модуля

Handle Application-Level Errors
msdnFor non-ASP.NET errors, you can create a custom handler in Internet Information Services (IIS)

В IIS6 на Win2003 раньше прогу от port 80 ставил. Фильтром рядом с ISAPI цеплялась и фильтровала всё и вся - и заголовки подменяла и ошибки пробрасывала на нужные урлы и всё такое прочее. Только вот на хостинге подобное не воткнёшь.

С сайта ms - "Http.sys является драйвер режима ядра, который обрабатывает HTTP-запросы." А дойдёт ли тогда запрос до этого самого "custom handler in Internet Information Services (IIS)"?

Интересно, есть ли возможность на хостинге подменить им http.sys на свой

st_stВ httpErrors не пробовал, так как секция не работает (добавление <error> никак не отражаются на сайте) и её атрибуты не разблокируются, как её включить и разблочить пока не знаю (удаление lockAttributes из applicationHost.config и магическая строка %windir%\System32\inetsrv\appcmd unlock config -section:system.webserver\httperror не помогли.

Возвращаясь к своему же вопросу, есть файлы с конфигурацией системы - applicationHost.config в \inetpub\history\ (новые копии создаются при запуске пула) и там действительно залочены атрибуты, но это лишь копия, сформированая из каких-то конфигов. И собственно сам вопрос - на основе чего строится этот файл? Есть ещё один файл с таким же именем в \Windows\System32\inetsrv\config\, но по внутреннему содержанию он имеет мало общего с реальным applicationHost.config из history. Какая-то штуковина лочит пару атрибутов и вырубает секцию httpErrors в web.config, то есть если даже не использовать лоченые атрибуты и прописать обработчик к примеру на ту же 404, то до него дело не доходит. При этом всё прекрасно работает, если указать в <customErrors>.

Нашёл, разблочить можно в диспетчере IIS выше уровнем (на имени компьютера). А <httpErrors> можно "включить", добавив атрибут existingResponse="Replace".