Re: реакция image_filter на return

[GD <gd@xxxxxxxxxxx>]

On Thu, 12 Jan 2012 23:58:07 +0400
Maxim Dounin <mdounin@xxxxxxxxxx> wrote:

> Hello!
> 
> On Thu, Jan 12, 2012 at 09:43:44PM +0400, GD wrote:
> 
> > On Thu, 12 Jan 2012 21:00:03 +0400
> > Maxim Dounin <mdounin@xxxxxxxxxx> wrote:
> > 
> > > Hello!
> > > 
> > > On Thu, Jan 12, 2012 at 12:15:03AM +0400, GD wrote:
> > > 
> > > > Доброго времени суток,
> > > > 
> > > > Наткнулся на багофичу:
> > > > 
> > > > Пример чуть синтетический, но рабочий:
> > > > 
> > > > location /r/ {
> > > >     if ( $uri = "/r/want_403" ) {
> > > >         return 403;
> > > >     }
> > > > 
> > > >     rewrite ^/r/(.+)$ /$1 break;
> > > > 
> > > >     proxy_pass http://host.tld;
> > > > 
> > > >     image_filter resize 100 100;
> > > > }
> > > > 
> > > > proxy_pass ожидаемо реагирует на return и никуда не ходит
> > > > но image_filter не взирая на 403 (Forbidden) пытается отработать,
> > > > в результате отдавая 415 (Unsupported Media Type)
> > > > 
> > > > Смотрел на ngx_http_addition_module, там реакция на return
> > > > полностью соответсвует док-ции. Т.е. если срабатывает return 403,
> > > > то add_after_body уже не отрабатывает.
> > > > 
> > > > Получилось полечить image_filter патчем (см. аттач).
> > > > Хочется услышать мненеие разработчиков.
> > > 
> > > Image filter расчитан на то, что он обрабатывает в т.ч. untrusted 
> > > ответы со сторонних серверов, и поэтому какая-либо фильтрация по 
> > > кодам ответов - не производится.
> > 
> > не очень логично на мой взгляд, но понятно
> > и, да, мой патч уже не кажется мне решением
> > 
> > не понятно все же почему return не завершает любую дальнейшую обработку
> > код ответа здесь не играет роли
> 
> Потому что image_filter - это фильтр, а return - возвращает ответ, 
> который потом проходит через этот фильтр.  Чтобы ответ через 
> фильтр не проходил - надо передать обработку в другой location, 
> где этот фильтр выключен.

ок, с этим ясно.

а почему в ngx_http_addition_module наоборот?
он не "расчитан на то, что он обрабатывает в т.ч. untrusted
ответы со сторонних серверов"?

> 
> > > Правильное решение - обарабатывать 403-ю ошибку в отдельном 
> > > location'е.  Если говорить конкретно о вышеприведённой 
> > > конфигурации, то очевидно так:
> > > 
> > >     location /r/ {
> > >         ...
> > >         image_filter ...
> > >     }
> > > 
> > >     location = /r/want_403 {
> > >         return 403;
> > >     }
> > 
> > заменил return на rewrite ... last
> > на этому видимо и остановлюсь
> > 
> > > 
> > > В общем случае - через error_page 403.
> > 
> > про error_page - не понял
> 
> Конструкция
> 
>     error_page 403 = /somewhere;
>     return 403;
> 
> даёт приблизительно тот же эффект, что и rewrite ... last.

да, действительно
обратно спасибо

> 
> Maxim Dounin


-- 
GD <gd@xxxxxxxxxxx>

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