Problem with ssi, proxy_pass and gzip

[Maxim Dounin]

Hello!

On Tue, Sep 02, 2008 at 12:35:03PM +0500, Rauf Kuliyev wrote:

>Здравствуйте,
>
>В процессе экспериментов, в архив попал испорченный c2.html, подправил.

Прилагаемый патч проблему исправляет, однако я не уверен в его 
оптимальности.

To Игорь: посмотри пожалуйста.  Что именно происходит я постарался 
описать в заголовке патча.

Maxim Dounin

>
>nginx -V
>
>nginx version: nginx/0.7.13
>configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt=-I
>/usr/local/include --with-ld-opt=-L /usr/local/lib
>--conf-path=/usr/local/etc/nginx/nginx.conf
>--sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
>--error-log-path=/var/log/nginx-error.log --user=www --group=www
>--with-debug --http-client-body-temp-path=/var/tmp/nginx/client_body_temp
>--http-proxy-temp-path=/var/tmp/nginx/proxy_temp
>--http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
>--http-log-path=/var/log/nginx-access.log --with-http_realip_module
>--with-http_ssl_module --with-http_stub_status_module
>
>Полный дебаг лог (беспроблемный запрос, следом проблемный), лежит в
>http://test2.day.az/files.tgz и отдельно тут:
>http://test2.day.az/nginx-error.log
>
>Рауф
>
>
>2008/9/1 Maxim Dounin <mdounin at mdounin.ru>
>
>> Hello!
>>
>> On Mon, Sep 01, 2008 at 05:07:21PM +0500, Rauf Kuliyev wrote:
>>
>>  Доброго времени суток,
>>>
>>> Имеется проблема при совместном использовании ssi, proxy_pass и gzip.
>>> Проверялось на 0.6.32 и 0.7.11
>>>
>>> Все упоминаемые файлы доступны на http://test2.day.az/files.tgz
>>>
>>> Имеются два тестовых адреса:
>>> 1) http://test2.day.az/test1.html - открывается только если отключена
>>> выдача
>>> гзипом
>>> 2) http://test2.day.az/test2.html - открывается при любых обстоятельствах
>>>
>>> В обоих файлах имеется 2 директивы #include, причем первый #include идет
>>> через proxy_pass на другой сервер, а второй локальный. Отличаются тесты
>>> только тем, что test2.html делает #include файла который размером меньше
>>> на
>>> 1 байт.
>>>
>>
>> Just FYI: В files.tgz - локальные файлы отличаются далеко не только на 1
>> байт.  В том, что инклудится в test1.html - вообще бинарный мусор.
>>  Воспроизвести не удалось.
>>
>>  Если отключить gzip или proxy_buffering, то проблема не наблюдается.
>>> Если директивы в тестах переставить местами (то есть сначала инклудить
>>> локальный файл, а потом удаленный), то проблема также не наблюдается.
>>>
>>
>> Было бы замечательно, если бы можно было посмотреть на вывод nginx -V и на
>> отладочный лог с проблемой и без.  Желательно от 0.7.13.
>>
>> Maxim Dounin
>>
>>
-------------- next part --------------
# HG changeset patch
# User Maxim Dounin <mdounin at mdounin.ru>
# Date 1220377458 -14400
# Node ID 4a1b52e95a773f05474a2ea3d2d971e21b88f9e1
# Parent  9205084bd1f3805a25a4e9ac5ee7067ad6697621
Make sure write handler for correct request will be called.

If complex reply was buffered after postpone filter (e.g. in gzip filter
module), and this happened just after switching to next postponed subrequest,
the copy filter has no chance to reclaim freed buffers and send more data.

To resolve this, just post an additional write event in ngx_http_writer()
if we got NGX_AGAIN and subrequest has been changed.

diff --git a/src/http/ngx_http_request.c b/src/http/ngx_http_request.c
--- a/src/http/ngx_http_request.c
+++ b/src/http/ngx_http_request.c
@@ -1968,6 +1968,11 @@ ngx_http_writer(ngx_http_request_t *r)
                    rc, &r->uri, &r->args);
 
     if (rc == NGX_AGAIN) {
+        if (r != c->data) {
+            ngx_post_event(wev, &ngx_posted_events);
+            return;
+        }
+
         clcf = ngx_http_get_module_loc_conf(r->main, ngx_http_core_module);
         if (!wev->ready && !wev->delayed) {
             ngx_add_timer(wev, clcf->send_timeout);