> в переменные $args и $query_string заносятся данные исходного запроса.
> >> A> как GET/POST от исходного запроса получить...
> >> * $args, эта переменная равна аргументам в строке запроса;
> >> http://sysoev.ru/nginx/docs/http/ngx_http_core_module.html
...
Во-первых, из документации, ...$query_string, то же самое, что и $args;...
Во-вторых, повторюсь, заносится туда СТРОКА ВЫЗОВА САМОЙ SSI-ВСТАВКИ,
то есть, в $args будет, как уже сказано:
> A> <!--# include virtual="/remote/body.cgi" --> не получит ничего
> A> <!--# include virtual="/remote/body.cgi?name=val" --> получит "name=val"
В-третьих, POST туда НЕ ПРИХОДИТ. Может у меня что-то не так? В
конфиге есть такое:
location /remote/ {
proxy_set_header X-URI $uri;
proxy_set_header X-ARGS $args;
proxy_pass http://localhost:32768;
}
(и, опять же, в X-ARGS будет соотв-нно "ничего" или "name=val")
Отсюда, в-четвертых:
> Игорь, а нельзя ли ввести некий параметр к SSI (типа yes/no),
> указывающий передавать ли в этот запрос исходные заголовки от клиента
> (просто, весь GET/POST)? Есть сложности?
Как я уже понял, заголовки клиента приходят и к SSI-запросу, это для
GET работает ЧАСТИЧНО (потому что все таки параметры строки исходного
запроса не приходят, а приходят те, которые в строке вызова
SSI-вставки).
Примерно то же и с POST. Тут тоже SSI достаются только заголовки, а
тело POST'а не приходит.
На мой взгляд такая "фича" как "(yes/no) передавать ВЕСЬ запрос
клиента" выглядит вполне полноценной частью SSI функционала.
(Да, это может быть слегка "неправильный" запрос, но пусть у
запрашиваемого скрипта будет возможность получить его, и скрипт-то
есс-но "подготовлен" к такому режиму работы).
--
engineer