Re[4]: Ошибка в SSI encoding
Илья Винокуров
ilvin at mail.ru
Thu Apr 9 14:06:52 MSD 2009
> > Очень хорошо будет, если nginx строку "/page?one=1;two=2" будет разбирать так же,
> > как ее интерпретирует бекенд...
>
> А может оставить интерпретацию этой строки для backend, а nginx будет
> просто ее пересылать.
Поздно. nginx уже влез в это болото:
http://sysoev.ru/nginx/docs/http/ngx_http_core_module.html#underscores_in_headers
В разделе встроенные переменные есть:
# $arg_name, эта переменная равна аргументу name в строке запроса;
Т.е. nginx уже парсит query_string и эти переменные очень удобно использовать
в rewrite и ssi.
> > Думаю, что в данной ситуации хорошо бы иметь возможность задать в конфигурации разделитель
> > QUERY_STRING, например
> > query_string_separator=[&]
> > query_string_separator=[;]
> > query_string_separator=[&;]
> > Где [] задает множество символов, которые распознаются как разделители.
> Это сделать возможно, но надо понимать что это может понизить
> производительность парсера запроса клиента.
Мы даже не заметим понижения производительности... Нужно будет внести небольшое
изменение в уже существующий парсер.
> > И про encoding="url" - здесь тоже ситуация не однозначная. Я бы обязательно кодировал
> > символы: '?','&',';','=','/', так как эти символы могут ввести в заблуждение парсер
> > query_string сервера.
>
> почему?
Допустим я традиционалист и использую в URL только '&', про ';' даже не знаю. Но
люблю CGI.pm...
В SSI nginx я пишу:
<!--# set var="content" value="ab;cd;gw" -->
<a href="http://host/script.pl?a=2&content=<!--# echo var="content" escape="url" -->">x</a>
Получается URL http://host/script.pl?a=2&content=ab;cd;gw
И чему будет равен content ?
PHP: content=ab;cd;gw
CGI.pm: content=ab
И зачем нам эти дополнительные грабли ?
Ведь http://host/script.pl?a=2&content=ab%3Bcd%3Bgw
Везде будет content=ab;cd;gw
С почтением,
Илья Винокуров.
More information about the nginx-ru
mailing list