Комментарии 56
Чем люди не занимаются, лишь бы не пользоваться нормальными веб-серверами…
субъективно слишком, ИИС — вполне себе сервер, не всем под лампой жить нравится
Он, конечно, веб-сервер, но даже 404 ошибку без обработки напильником отдать не может. А так вполне себе веб-сервер, да.
Вы не в теме, товарищ, совсем.
угу. Куда уж нам, сирым, все эти премудрости веб-серверов от майкрософта постигнуть. Нам бы для начала понять, где находится «рабочий стол» — в корне файловой системы или таки в профиле пользователя…
ознакомился с вашим профилем: дискуссию считаю бессмысленной :)
Тролль, такой толстый тролль.
В этом ты признался в своём профиле. Будь добр, метай своё говно в других топиках.
А за статью спасибо, очень полезно
В этом ты признался в своём профиле. Будь добр, метай своё говно в других топиках.
А за статью спасибо, очень полезно
Начать ликбез можно с того, что данная фича к IIS не имеет вообще никакого отношения. Он даже уважаемым TC не упоминался, так что причина, по которой вы его вспомнили — не ясна. Продолжить можно тем, что конкретно этот инструмент был создан именно для редиректа. О чем можно было бы догадаться, увидев опции defaultRedirect, redirect и т.п. Т.е. он работает именно так, как задумывался, что справедливо может вызвать праведный гнев :)
Ну автор за людей до странностями не в ответе, он-то нормальным веб-сервером пользуется…
АААА! Чилавек-ашипка!
В IIS 7 потребуется даже при параметре runAllManagedModulesForAllRequests=«true» в Web.config настроить блок httpErrors в system.webServer или будут проблемы с обработкой url'ов директорий, например:
Также требуется добавить Server.ClearError(); перед трансфером на страницу с ошибкой.
<httpErrors errorMode="DetailedLocalOnly" defaultResponseMode="ExecuteURL">
<remove statusCode="403" />
<remove statusCode="404" />
<remove statusCode="500" />
<error statusCode="403" path="/Pages/Errors/Forbidden.aspx" />
<error statusCode="404" path="/Pages/Errors/NotFound.aspx" />
<error statusCode="500" path="/Pages/Errors/ServerError.aspx" />
</httpErrors>
Также требуется добавить Server.ClearError(); перед трансфером на страницу с ошибкой.
>SEO оптимизатор недоволен
рассмешили, рассмешили.
рассмешили, рассмешили.
ах, да: неужели IIS настолько ущербен, что по дефолту при ошибке редиректит юзера х.з. куда? а если я ошибся в урле и хочу его исправить?
вы путаете IIS и ASP.Net
В IIS есть предопределенные error pages на каждый тип ошибки.
Эти страницы можно выключать или для всего хоста, или для конкретного сайта.
Вот так можно выключить обработку 404 ошибки совсем:
Эти страницы можно выключать или для всего хоста, или для конкретного сайта.
Вот так можно выключить обработку 404 ошибки совсем:
<configuration>
<system.webServer>
<httpErrors>
<remove statusCode="404"/>
</httpErrors>
</system.webServer>
</configuration>
на всякий случай, тем кто не понял, речь в статье не о IIS вовсе. речь об особенности платформы ASP.NET и именно настройки ее самой, а не сервера где она крутится. Настройки ASP.NET != настройки IIS
не совсем так — это настройка конфигурации узла, на стыке с рантаймом, но все-таки больше к серверу относится
ASP.NET, а точнее aspnet_isapi.dll — это один из ISAPI extensions под IIS. И обработкой файла web.config, частью которого является рассматриваемый раздел занимается исключительно он. Если быть совсем точным, то метод HandleError класса System.Web.UI.Page. Естественно, IIS о нем не знает вообще ничего. Взял первый попавшийся в сети пример — support.asus.com/test.aspx. Работает, как и декларировано, через редирект, поскольку обрабатывается aspnet_isapi.dll. Но стоит поставить расширение html, которое в данном случае им не обрабатывается — support.asus.com/test.html, так сразу видим родную ошибку 404 от IIS без всяких редиректов.
исчерпывающе. убедили!
«ASP.NET, а точнее aspnet_isapi.dll — это один из ISAPI extensions под IIS»
ASP.NET Runtime в IIS7 уже намертво интегрирован в сам сервер, а не просто существует как ISAPI-расширение. Integrated Pipeline Mode там, вроде как, по-умолчанию же включен.
ASP.NET Runtime в IIS7 уже намертво интегрирован в сам сервер, а не просто существует как ISAPI-расширение. Integrated Pipeline Mode там, вроде как, по-умолчанию же включен.
Частично так. В IIS нет сложной цепочки IIS->ISAPI->ASP.NET, теперь ASP.NET полноправный участник IIS7 pipeline'а, но при этом он просто один из ExecuteHandler's в нем, который может быть, а может и не быть. И если зайти в настройки сайта, то в разделе IIS мы увидим свои Error Pages, а в разделе ASP.NET — свои ".NET Error Pages". И error pages IIS'а, как и полагается, о web.config ничего не знают.
Статья очень хорошая и полезная.
А неадекватные комментарии пользователей линукса как были, так и будут на хабре — не обращайте на них внимания. Единственное, что жаль, что полезные статьи из-за таких людей часто не попадают на главную.
А неадекватные комментарии пользователей линукса как были, так и будут на хабре — не обращайте на них внимания. Единственное, что жаль, что полезные статьи из-за таких людей часто не попадают на главную.
Подписка на конкретный блог решает данную проблему. =)
Плюсанул топик, чтобы статья попала на главную и даже линуксоиды увидели, что в ASP.NET даже 404 без костылей отдать нельзя.
Это не костыли, это то, как 404 можно преобразовать в user-friendly сообщение об ошибке.
Мы в вебе или где? 404ая страница должна быть 404ой, а не 302+200. А после ваших «user-friendly сообщений об ошибке» даже URL поправить нельзя, чтобы понять, где ошибся.
Так в статье достаточно доходчиво написано, какое событие нужно перехватить, чтобы сделать всё, что вашей душе угодно.
Вас не устраивает гибкость такого архитектурного решения?
Вы хотите кнопку — do what i mean?
Вас не устраивает гибкость такого архитектурного решения?
Вы хотите кнопку — do what i mean?
Меня крайне смущает содержание топика. Смотрите, мы имеем неправильное и контринтуитивное поведение по умолчанию, для настройки которого отведена целая секция в конфигурационном файле. Если же мы хотим сделать поведение нормальным, то необходимо руками написать 10 строк кода, причём не то чтобы совсем очевидного кода (что делает Server.Transfer?). Мне представляется это просчётом в архитектуре: поведение по умолчанию не соответствует ожидаемому, общепринятому. Что, конечно, вполне в духе майкрософта, и на мой взгляд может быть обозначено эпитетом «костыль».
Вы путаете концепции — ASP.NET — это технология построения web-приложений,
где программист, а не web-server решает, как обрабатывать ошибки.
Программист может пользоваться default обработчиком ошибок, который конфигурится через web.config или обработать ошибку так, как ему угодно.
Что здесь контринтуитивно и неправильно? Вы с концепцией exception (try-catch) знакомы?
где программист, а не web-server решает, как обрабатывать ошибки.
Программист может пользоваться default обработчиком ошибок, который конфигурится через web.config или обработать ошибку так, как ему угодно.
Что здесь контринтуитивно и неправильно? Вы с концепцией exception (try-catch) знакомы?
Не держите меня я не знаю за кого, я конечно в курсе того, что такое исключения. Да и в любой более-менее уважающей себя технологии построения веб-приложений именно программист решает, как ему обрабатывать ошибки. Я говорю о странных умолчаниях. Default обработчик имеет странное поведение. Собственно это топик и знакомит читателя с тем, как это умолчательное поведение изменить на то, которое и должно быть умолчательным. Может показаться, что это неважный вопрос — ведь всего десятью строчками кода можно сделать поведение нормальным. Однако многие программисты могут рассчитывать на это поведение по умолчанию, строить с его учётом свои приложения. И имея большое приложение, которое рассчитывает на «стандартное» поведение, может оказаться, что десятью строками кода не обойтись.
А чего такого странного в default обработчике ошибок?
Если вы в нем ничего не наконфигурили — выдает обычный 404. Без редиректов и без ничего.
Что вас еще не устраивает?
Если вы в нем ничего не наконфигурили — выдает обычный 404. Без редиректов и без ничего.
Что вас еще не устраивает?
По умолчанию выдается 404. В web.config есть простая возможность сконфигурировать обработку запросов. Есть global.asax, в котором можно писать что угодно и обрабатывать как угодно. Кроме того, вы можете написать свои хендлеры. И даже вы можете настроить все через IIS.
В статье же описано, как совместить гибкость встроенных возможностей конфигурации и полностью удовлетворить запросы SEO-специалистов. А для того, чтобы просто возвратить 404, не нужно вообще ничего делать.
В статье же описано, как совместить гибкость встроенных возможностей конфигурации и полностью удовлетворить запросы SEO-специалистов. А для того, чтобы просто возвратить 404, не нужно вообще ничего делать.
Хорошо. Не просто, а возвратить 404, в теле ответа передав при этом HTML-код из конкретного файла.
Мне кажется странным местом этот самый global.asax. У вас (я обращаюсь и к LexL тоже) большой опыт разработки на ASP.NET? Никогда не было случая, что вот форум хочет 404ые обрабатывать таким образом, а новости писал другой человек, рассчитывавший на другое поведение? и приходится этот global.asax править руками чтобы всё работало как надо, расставляя километры if/switch?
Мне кажется странным местом этот самый global.asax. У вас (я обращаюсь и к LexL тоже) большой опыт разработки на ASP.NET? Никогда не было случая, что вот форум хочет 404ые обрабатывать таким образом, а новости писал другой человек, рассчитывавший на другое поведение? и приходится этот global.asax править руками чтобы всё работало как надо, расставляя километры if/switch?
Я так понимаю, что форум и новости — это разные приложения, лежат в разных папках с разными web.config.
Т.е. ничего не мешает для форума сконфигурить так, а для новостей — по-другому, как там другой человек считает нужным.
Кроме того, web.config — наследуются…
Т.е. ничего не мешает для форума сконфигурить так, а для новостей — по-другому, как там другой человек считает нужным.
Кроме того, web.config — наследуются…
Ну прочитайте статью же. Автору пришлось от той секции web.config отказаться вовсе, чтобы удовлетворить SEO-специалиста. Так что от наследования толка нет в данном случае.
тут есть один момент, в статье описана настройка ASP.NET и она имеет смысл если у вас нет доступа на IIS, то есть к примеру вы на шаред хостинге. Если у вас есть достпуп к IIS, то все эти настройки можно не использовать вовсе, ибо IIS будет все корректно возвращать как тут выше и писали и вы можете выставить на нем самом какую страницу отображать на ошибке ессно. То биш есть два способа решить проблему эту чтобы SEO спец был доволент 1) ничего не трогать в ASP.NET и иcпользовать настройки IIS 2) если у вас нет доступа к IIS то нужно делать то что в статье.
Даже так? Вам не кажется, что реакция на действия пользователя (в том числе и ошибочные) — дело веб-приложения, а веб-сервер тут не при чём? И что если коды ошибок и пути их обработки настраиваются внутри веб-сервера, то это некое нарушение уровня абстракции?
У разработчика есть выбор, а это всегда лучше если его нет. Вы можете настроисть это в IIS для вашего приложения, или же вы можете настроить это на уровне ASP.NET. Какой подход лучше это вопрос как известно филосовский :)
В том-то и дело, что разработчику дают выбор — либо все настроить на уровне приложения, либо на уровне отдельной директории либо на IIS. Даже можно основные настройки вынести в machine.config, который будет работать для всей машины.
Посмотрите здесь иерархию наследования настроек — там все очень логично и гибко.
Посмотрите здесь иерархию наследования настроек — там все очень логично и гибко.
Справедливости ради надо упомянуть, что с версии 3.5 есть параметр redirectMode, который может быть либо в режиме redirect, либо в режиме rewrite, который снимает вопрос с повестки дня :)
тока что протестил, не снимает проблемы, в случае redirectMode=ResponseRewrite редирект не происходит однако возвращаяется код 200 на нашей 404ой странице, что собственно и не приемлимо дле СЕО
а я всегда просто отключаю CustomErrorsModule и потом с помощью ErrorDocument делаю как нужно в конкретной ситуации.
Во-первых это не работает в ASP.NET MVC. (правда есть решения), но мне так и не удалось заставить это работать. Дошел до того, что когда используется самописный Transfer, происходит отрисовка страницы, но на этой странице нет ни сессии ни чего. и в итоге кое какие Views валятся, потому что приходят нулевые данные. Пока не нашел как это сделать нормально. Ах, да. и в Route — тоже не получается, потому что есть
routes.Add("Home", new LowercaseRoute("{action}/{id}",
new RouteValueDictionary(
new
{
controller = "Home",
action = "Index",
id = UrlParameter.Optional
}),
new MvcRouteHandler()));
routes.Add("Home", new LowercaseRoute("{action}/{id}",
new RouteValueDictionary(
new
{
controller = "Home",
action = "Index",
id = UrlParameter.Optional
}),
new MvcRouteHandler()));
ASP.NET был написан индусами, 100% инфа.
В Django достаточно создать шаблон 404.html, оформить как хочешь и все работает, отдает сразу 404 без всяких редиректов. Не надо ни одной строки кода.
В Django достаточно создать шаблон 404.html, оформить как хочешь и все работает, отдает сразу 404 без всяких редиректов. Не надо ни одной строки кода.
Ето все хорошо для страничек, а от что делать со статикой? Мапить свой хендер для .jpeg/.png/.sfw/.css и т.д. не очень то хочется — докачка может потерятся и т.д.
ну дык в статье как раз о том как обрабатывать по своему :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ASP.NET, HTTP 404 и SEO