Нужно ли читать буфер своими силами когда
инициализирован file и in_file = 1 ?
Например в ngx_http_*_body_filter ( ngx_http_request_t* r, ngx_chain_t* in )
пришло:
in->buf->pos = NULL
in->buf->last = NULL
in->buf->start = NULL
in->buf->end = NULL
in->buf->in_file = 1
in->buf->last_buf = 1
in->buf->last_in_chain = 1
...
В таком случае нужно брать дескриптор файла из in->buf->file и из него
читать?
Но я такого в готовых фильтрах не нашел.
Еще насчет контекстов:
static ngx_int_t ngx_http_my_header_filter ( ngx_http_request_t* r )
{
ngx_http_my_ctx_t* ctx;
if ( r != r->main ) return ngx_http_next_header_filter (r);
ctx = ngx_pcalloc(r->pool, sizeof(ngx_http_my_ctx_t));
if (ctx == NULL) return NGX_ERROR;
// Устанавливаем фактически только для r->main
ngx_http_set_ctx ( r, ctx, ngx_http_my_filter_module);
return ngx_http_next_header_filter (r);
}
static ngx_int_t ngx_http_tmpl_body_filter ( ngx_http_request_t* r,
ngx_chain_t* in )
On Thu, Jun 07, 2007 at 10:12:44PM +0400, Denis Erygin wrote:
>А как там может возникнуть зацикливание ?
Я имею ввиду то, что если в ngx_http_*_body_filter()
вызвать ngx_http_subrequest, то сервер войдет в цикл,
который прервется в конце концов core дампом (проверено).
В ngx_http_ssi_body_filter же используется специальная обработка,
предупреждающая повторный вызов ngx_http_subrequest в результате
работы предыдущего ngx_http_subrequest, которая мне не совсем понятна.
В ngx_http_ssi_body_filter ngx_http_subrequest() вызывается не от балды,
а когда в потоке встречается include. Если при парсинге ответа подзапроса
не будет найден include, то и ngx_http_subrequest() вызываться не будет.
>Контекст выставляется для каждого подзапроса. Вся обработка ssi хранится
>в контексте.
Т.е. не могу создать в контексте счетчик вызовов ngx_http_*_body_filter()
/ngx_http_subrequest,
т.к. сам контекст целиком постоянно обновляется?
Я бы хотел реализовать логику паттерна singleton для вызова
ngx_http_subrequest из
ngx_http_*_body_filter(), для этого нужен счетчик этих вызовов, чтобы
отличить основной
вызов ngx_http_*_body_filter() от пришедшего ответа к ngx_http_subrequest
(который также вызовет ngx_http_*_body_filter() ) - вот собственно и все..
Конечно, можно завести глобальную переменную, но
ngx_http_ssi_filter_module
такой подход не использует, вот и возникает вопрос, что там происходит.
Потому что в ngx_http_ssi_filter_module нет глобального контекста - ему
нечего там хранить. Зато есть сотни одновременных контекстов, связанных
с запросами.
Основной запрос от подзапроса отличается так:
основной: r == r->main
подзапрос: r != r->main
Пусть будет общий для всего модуля ngx_http_*_body_filter,
нужно отличить контекст его вызова для обычного запроса от ответа к
ngx_http_subrequest,
разбор исходников пока четкого ответа не дал.
----- Original Message -----
From: "Igor Sysoev" <is@xxxxxxxxxxxxx>
To: <nginx-ru@xxxxxxxxx>
Sent: Thursday, June 07, 2007 7:57 PM
Subject: Re: BugReport: ./configure --add-module неправильно подключает
filter модуль
On Thu, Jun 07, 2007 at 06:30:07PM +0400, Denis Erygin wrote:
>Какой механизм используется для блокирования зацикливания
>по ngx_http_subrequest в ngx_http_ssi_filter_module?
А как там может возникнуть зацикливание ?
>Насколько я понял, эмулируется сессия с помощью:
>ngx_http_get_module_ctx ( r, ngx_http_ssi_filter_module );
>ngx_http_set_ctx ( r, ctx, ngx_http_ssi_filter_module );
>
>Но я столкнулся с тем, что первый параметр "r" (ngx_http_request_t)
>в ngx_http_ssi_body_filter меняется после вызова ngx_http_subrequest,
>и ngx_http_get_module_ctx возвращает NULL, даже если заранее
>инициализировать через ngx_http_set_ctx в ngx_http_ssi_header_filter.
>
>Как это работает в ngx_http_ssi_filter_module?
Контекст выставляется для каждого подзапроса. Вся обработка ssi хранится
в контексте.
--
Игорь Сысоев
