Весьма странно. Вырезка из документации:
*syntax: *proxy_pass_unparsed_uri */[on|off]/*
*default: *proxy_pass_unparsed_uri off
*context: *http, server, location
Исправим.
Почему бы не определять эту директиву на уровне http? Мне было бы очень
удобно во всех server{} иметь собственное значение по умолчанию. То есть
допустимые контексты по идее не должны отличаться от proxy_buffers,
proxy_set_header и пр.
Потому что, proxy_pass работает как alias, то есть, для
location /one/ {
proxy_pass ;
}
в запросе меняется URI. А URI может быть например, таким:
"/one%2F%2E/page.html". nginx превращает этот URI в /one/page.html,
а proxy_pass - в /two/page.html. Если передавать unparsed uri, то
нужно понять, какая часть в /one%2F%2E/page.html соответствует /one/.
Поэтому, если задано proxy_pass_unparsed_uri, то в URI ничего не меняется,
а для того, чтобы всё работало, как ожидается, то область использования
proxy_pass_unparsed_uri ограничивается:
"proxy_pass_unparsed_uri" can be set for location "/" or given
by regular expression.
Segmentation fault происходит из-за того, что nginx пытается показать
это сообщение для разделов http и server.
Igor Sysoev wrote:
On Thu, 22 Sep 2005, Alexander Gnevshev wrote:
Директива "proxy_pass_unparsed_uri on;", помещенная на уровне http,
заставляет nginx вызывать segmentation fault при тестировании
конфигурации.
А ей там не место. Теперь будет писать "is not allowed here".
