Hello!

On Sun, Oct 23, 2011 at 05:55:06PM +0300, Sergey Kobzar wrote:

> On 10/23/11 17:49, Maxim Dounin wrote:
> >Hello!
> >
> >On Sat, Oct 22, 2011 at 06:08:43PM +0300, Sergey Kobzar wrote:
> >
> >[...]
> >
> >>Есть одна проблема при max_fails> 1 - клиенту будет одана
> >>стандартная error page, N раз (пока Nginx не выкинет дохлый бэкенд
> >
> >Это не имеет никакого отношения ни к max_fails (т.к. даже при
> >max_fails == 1 клиенту будет отдана ошибка, если таки ошибка
> >произойдёт), ни собственно к обсуждаемому вопросу (как
> >обрабатывать ошибки на фронтенде, и обрабатывать ли вообще, -
> >вопрос совершенно отдельный).
> >
> >>из пула). В принципе это не критично при высокой нагрузке, т.к.
> >>пострадают всего пару человек. Решение - описать custom error page 2
> >>раза - на фронтенде + на backup сервере.
> >
> >Я лично предпочитаю использовать proxy_intercept_errors, это
> >позволяет централизованно конфигурировать страницы ошибок на
> >фронтенде/ах. Но, по понятным причинам, такой подход не всегда
> >применим.
>
> Максим, а можно немного подробней про proxy_intercept_errors с
> примером? Из документации не совсем все понятно.


Директива proxy_intercept_errors позволяет перехватывать 4xx, 5xx
ошибки, возвращённые бекендом, и выдавать вместо них то, что
задано с помощью директивы error_page.

Пример:

location / {
proxy_pass http://backend;
proxy_intercept_errors on;
error_page 404 /404.html;
}

location = /404.html {
# serve static file here
}

Если бекенд ответит 404, то клиенту уйдёт ответ 404 с телом из
/404.html (а не то, что прислал бекенд).

> Если бэкенд сдулся окончательно, то что от него можно требовать?

Если бекенд сдулся окончательно - то proxy_intercept_errors роли
не играет. Он имеет смысл только в том случае, если бекенд ещё
способен вернуть ответ.

Maxim Dounin

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru