Apache + mod_proxy_uwsgi + php — не согласуется результат работы при сходных ProxyPass и ProxyPassMatch?

Question

[merlin-vrn]

Здравствуйте. Имеется указанная выше связка. uwsgi запущен на socket = 127.0.0.1:9093 с plugin = php54.


Если я в конфигурации виртуалхоста задаю
ProxyPass / uwsgi://127.0.0.1:9093/

uwsgi получает запрос (например, GET /phpinfo.php) и выполняет его без ошибок (в логе error_log виртуалхоста пусто). При этом в логах uwsgi образуется строка:

[pid: 6746|app: -1|req: -1/49] 2002:.... () {54 vars in 1068 bytes} [Wed Jun 19 22:46:38 2013] GET /phpinfo.php => generated 58540 bytes in 13 msecs (HTTP/1.1 200) 2 headers in 82 bytes (0 switches on core 0)

и ещё две похожих строки — лого php из phpinfo.


Но если задать в виртуалхосте вместо ProxyPass директиву
ProxyPassMatch ^/(.*)$ uwsgi://127.0.0.1:9093/$1

что (согласно документации Apache) совершенно то же самое, что и выше, то происходит странное: в error_log виртуалхоста появляется строка

[Wed Jun 19 20:08:59 2013] [error] [client 2002:...] URL uwsgi://127.0.0.1:9093/phpinfo.php: proxy:reverse proxy:uwsgi://127.0.0.1:9093/phpinfo.php .0.1:9093/phpinfo.php

а в логах uwsgi —

[pid: 6018|app: -1|req: -1/31] 2002:.... () {50 vars in 1040 bytes} [Wed Jun 19 19:58:15 2013] GET /phpinfo.php => generated 0 bytes in 0 msecs (HTTP/1.1 404) 0 headers in 61 bytes (0 switches on core 0)

Пробовал задавать uwsgi опции типа php-*, например, php-docroot, не помогает.


(на адрес клиента внимание не обращаем — ipv6)


Вообще ProxyPassMatch предполагалось использовать с выражением ^/(.*\.php)$, чтобы передавать uwsgi только запросы к php.


И в том, и в другом случае конфгиурация uwsgi идентичная (и он вообще не перезапускался), и судя по логу, запрос от апача к нему приходит одинаковый (GET /phpinfo.php). Но почему в первом случае он находит файл и выполняет его, а во втором нет? В чём разница вообще для uwsgi, каким способом на него завернули запрос? Как сделать, чтобы поведение uwsgi не зависело от конфигурации apache? Как всё это отлаживать?


P.S. Сразу хочу предупредить: не надо предлагать использовать nginx и так далее. Для этого всё и делается, но нельзя просто так взять и заменить вебсервер. Стратегия перехода выбрана такая: постепенно переключать виртуалхосты на uwsgi, а когда mod_php останется в прошлом, уже реально будет резко заменить apache на nginx. И для этого сейчас нужно именно завести uwsgi с apache.

Comments

[merlin-vrn]

Итак, залез в исходники mod_proxy_uwsgi, там в функции

static int uwsgi_send_headers(request_rec *r, proxy_conn_rec *conn)

есть строка

const char *path_info = apr_table_get(r->subprocess_env, "PATH_INFO");

Вот уже на этом этапе в path_info некорректная строка. Таким образом, ошибка глубже, где-то в пакете apr или дальше. Другими словами, uwsgi тут вообще не при чём, баг непосредственно в Apache. Осталось проверить, есть ли он в свежайшей версии.

Answer 1

[merlin-vrn]

В общем, с помощью грубого костыля в файле apache2/mod_proxy_uwsgi.c вида

16a17
> #include <string.h>
104a106,113
>     const char *_path_info = apr_table_get(r->subprocess_env, "PATH_INFO");
> 
>     if (script_name && _path_info && (script_name[0] != _path_info[0])) {
>         // APR bug where value in path_info doesn't correspond to what is defined in CGI spec http://tools.ietf.org/html/rfc3875#section-4.1.5
>         // we'll fix it here by ourselves, scanning to first '/' and erasing everything before it
>         apr_table_set(r->subprocess_env, "PATH_INFO", strchr(_path_info, '/'));
>     }
> 

удалось запустить работу как надо.

Answer 2

[joneleth]

Отсниффайте оба запроса tcpdump-ом и сравните, может что-то найдется.
А вообще непонятно для чего вам uwsgi в принципе.

Comments

[merlin-vrn]

Действительно, в pcap совпадает REQUEST_URI ("/phpinfo.php"), но вот PATH_INFO в правильном случае тоже "/phpinfo.php", а в неправильном — «0.0.1:9093/phpinfo.php». А написал в апаче localhost вместо 127.0.0.1 — стало «lhost:9093/phpinfo.php».
Видимо, логирует uwsgi REQUEST_URI, а для поиска файла использует PATH_INFO. То, что он неверный, конечно заслуга mod_proxy и mod_proxy_uwsgi; то, что логируется одно, а используется другое — самого uwsgi.

Спасибо, проблема теперь хотя бы прояснилась.