Re: location + rewrite и (де)кодирование URI

[Evgeniy Berdnikov]

On Wed, Jun 19, 2019 at 02:54:10PM +0300, Maxim Dounin wrote:
> On Tue, Jun 18, 2019 at 04:45:13PM +0300, Gena Makhomed wrote:
> 
> > On 18.06.2019 15:26, Maxim Dounin wrote:
> > 
> > > И снова эксперимент плохой, негодный.
> > 
> > Вот полный конфиг тестового сервера:
> > 
> > server {
> >      listen 8080;
> > 
> >      location /wiki1/ {
> >          rewrite ^/wiki1/(.*) https://$host/$1;
> >      }
> > 
> >      location /wiki2/ {
> >          rewrite ^/wiki2/(?<title>.*) https://$host/$title;
> >      }
> > }
> > 
> > Вот запросы к первому и второму location`у:
> > 
> > $ curl -I http://127.0.0.1:8080/wiki1/%D1%82%D0%B5%D1%81%D1%82
> > Location: https://127.0.0.1/%D1%82%D0%B5%D1%81%D1%82
> > 
> > $ curl -I http://127.0.0.1:8080/wiki2/%D1%82%D0%B5%D1%81%D1%82
> > Location: https://127.0.0.1/тест
> > 
> > Первый и второй location отличаются между собой только тем,
> > что в первом используется неименованное выделение $1,
> > а во втором - именованное выделение $title.
> > 
> > И в то же время получаем такие разные результаты. Почему так?
> 
> Потому что подстановка $1 делается из раскодированного URI 
> запроса, и nginx знает, что данные в ней следует экранировать.  А 
> $title - произвольная переменная, и как и любая произвольная 
> переменная - подставляется в предположении, что данные в ней 
> корректно экранированы.

 Выглядит крайне непоследовательно (а если отбросить политкорректность,
 так это просто вынос мозга).

 IMHO, лучше было бы принять соглашение, что rewrite работает на уровне
 раскодированных URI и его результат подлежит кодированию.
 Для вставки уже кодированных строк понадобится функция декодирования,
 зато схема будет простой и предельно ясной.
-- 
 Eugene Berdnikov