В принципе, я пытаюсь понять, как PHP можно вызывать с «веб-сервера».
Я прочитал документацию, но это мало помогло.
Насколько я могу судить, есть три способа вызвать PHP:
php -f "/path/to/script.php" ) Итак, начнем с CGI . Возможно, я просто слепой, но в спецификации не упоминается, как на веб-сервере веб-сервер передает данные (заголовки и обратные вызовы) на предмет реализации CGI. С FastCGI ситуация еще хуже.
Затем, у нас есть серверные модули, которые, я даже не знаю, что искать, поскольку все никуда не ведутся.
Вызов сценария CGI довольно прост. PHP имеет несколько особенностей, но вам в основном нужно настроить список переменных окружения, а затем вызвать двоичный код PHP-CGI:
setenv GATEWAY_INTERFACE="CGI/1.1" setenv SCRIPT_FILENAME=/path/to/script.php setenv QUERY_STRING="id=123&name=title&parm=333" setenv REQUEST_METHOD="GET" ... exec /usr/bin/php-cgi
Большинство из них являются шаблонами. SCRIPT_FILENAME – это то, как вы передаете фактическое имя файла php интерпретатору PHP, а не как параметр exec. Ключевым для PHP является также нестандартная переменная REDIRECT_STATUS=200 .
Для запроса GET вам нужны только переменные окружения. Для запроса POST вы просто передаете тело запроса HTTP как stdin в исполняемый двоичный файл php-cgi. Возвращаемый stdout – это ответ CGI, состоящий из неполного HTTP-заголовка, \ r \ n \ r \ n и тела страницы.
(Только из памяти. Может быть, еще несколько ошибок.)
FastCGI, вероятно, является лучшим вариантом, поскольку он настолько разумно используется, что даст вам независимость от языка (например, вы могли бы упасть в Ruby позже), и это хорошо документировано с большим количеством примеров .
Вы можете написать свой собственный API Сервера, если хотите, но это сложнее, чем реализация FastCGI и имеет несколько недостатков.
Я бы не стал вообще беспокоиться о прямых CGI, FastCGI существует по какой-то причине.