Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: реакция image_filter на return
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,
где этот фильтр выключен.
> > Правильное решение - обарабатывать 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
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru
|