Нелогичное поведение error_page

[bas]

Я почему-то полагал что если error_page описаны для разных кодов, оно
пронаследуется. Спасибо за разъяснение :)

24 ноября 2009 г. 16:28 пользователь Igor Sysoev <igor at sysoev.ru> написал:

> On Tue, Nov 24, 2009 at 03:15:56PM +0500, bas wrote:
>
> > Здравствуйте! Столкнулся вот с такой проблемой:
> >
> > На уровне server объявлено:
> > ---
> > deny all;
> > error_page 403 /prof-upgrade.html;
> > location /prof-upgrade.html {
> > allow all;
> > }
> > ---
> >
> > Осуществляется обработка 404 ошибки для скриптов, чтобы выдавало
> стандартную
> > страницу ошибки вместо "No input file specified":
> > ---
> > location @404 {
> > internal;
> > }
> > location ~ \.php$ {
> > error_page 404 @404;
> > fastcgi_intercept_errors on;
> > ...
> > }
> > ---
> >
> > В данном случае директива "error_page 403 /prof-upgrade.html;" не
> > срабатывает в скриптовом локейшене.
> > Если убрать "error_page 404 @404;" или добавить туда "error_page 403
> > /prof-upgrade.html;", то все нормально - выдается
> > содержимое /prof-upgrade.html
>
> http://sysoev.ru/nginx/docs/http/ngx_http_core_module.html#error_page
>
> Директивы наследуются с предыдущего уровня при условии, что на данном
> уровне не описаны свои директивы error_page.
>
>
> --
> Игорь Сысоев
> http://sysoev.ru
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://nginx.org/mailman/listinfo/nginx-ru
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20091124/38d74385/attachment-0001.html>