У меня следующая установка:
Теперь мой вопрос: как мне настроить прокси-сервер (полностью настраиваемый apache 2.2 с PHP 5.3) для интерпретации простых файлов php с Plain-Server?
Пример: задан небольшой php-скрипт "hello.php" на обычном сервере (доступный через http: //plainserver/hello.php):
<?php
echo "Hello World";
?>
Plain-Server выводит его только как обычный текст, без разбора php-кода.
На Прокси-сервере файл hello.php не существует. Но при запросе hello.php с прокси-сервера он должен получить hello.php с простого сервера с помощью mod_proxy (обратный прокси). Он также должен проанализировать и выполнить php, говоря только «Hello World».
Обратный прокси уже запущен, но выполнение PHP-кода не работает. Я попробовал mod_filter, но не смог заставить его работать. Есть идеи, как это сделать? (Примечание: также размещено на stackoverflow.com)
Я нашел другой способ с mod_ext_filter. Добавьте в свой httpd.conf следующее:
ProxyPass /test/ http://localhost:9000/
<IfModule mod_ext_filter.c>
ExtFilterDefine parse-php mode=output intype=text/html cmd="/usr/bin/php"
</IfModule>
ProxyPassReverse /test/ http://localhost:9000/
<LocationMatch "\.php">
SetOutputFilter parse-php
</LocationMatch>
Таким образом, он запускает внешнее приложение php, которое находится в / usr / bin /. Плохо: запуск отдельного процесса, а также парсинг php-файлов, не входящих в папку / test /.
Я также пытался использовать fast-cgi или mod_php для анализа php-файла, но не смог заставить его работать. Есть идеи, как использовать fast-cgi для интерпретации php-файла?
Вы этого не сделаете. Во всяком случае, не с mod_proxy. У вас может быть прокси-скрипт PHP, который запрашивает контент и обрабатывает его, но ... тьфу.
Что бы вы ни делали, справедливо будет сказать, что вы делаете это неправильно.
У меня была аналогичная проблема - в моем случае основной сервер «Plain Text» мог анализировать XQuery в HTML, но не в PHP. Поэтому я решил восполнить этот пробел с помощью Apache, но также хотел, чтобы весь сайт был автономным, для упрощения резервного копирования.
Я решил это, установив Apache DocumentRoot в тот же каталог, из которого главный сервер обслуживает файлы, затем используется ProxyPassMatch для сопоставления с запросами, заканчивающимися на .php, и сказал mod_proxy не проксировать эти файлы, добавив ! до конца инструкции директивы:
DocumentRoot "/path/to/localhost.main/
…
ProxyRequests off
ProxyPassMatch ^/(.*\.php)$ !
ProxyPass / http://localhost.main:8080/
ProxyPassReverse / http://localhost.main:8080/
ProxyPassReverseCookieDomain localhost.proxy localhost.main
Таким образом, все файлы PHP анализируются (в моем случае через FastCGI, но также должны работать с mod_php) и обслуживаются Apache, а остальные передаются на главный сервер.
Я также переписывал поверх этого, хотя, чтобы сопоставить классные URI с обрабатывающим скриптом с параметрами запроса, который требует, чтобы другое правило работало правильно, хотя здесь логика инвертирована, как и отрицание внутри самого регулярного выражения (с использованием отрицания смотреть за):
RewriteRule ^/(.*(?<!\.php))$ /path/to/script/$1 [L,PT,QSA]
это действительно плохое решение ... но на прокси-машине не настраивайте проксирование, вместо этого добавьте
ErrorDocument 404 /index.php
а в index.php поместите логику, которая проверяет $ _SERVER ['REQUEST_URI'], загружает код с сервера содержимого и выполняет его с помощью eval.
но вот и плохо, включить не получится ... вомбл правильный. просто попробуйте другой подход. если вы действительно в отчаянии, возможно, используйте webdav и davfs, но это все еще уродливый взлом, nfs будет намного эффективнее, если вы будете настаивать на размещении кода на одной машине и интерпретации на другой.