[php] Реализация разрыва http соединения до окончания работы скрипта

а просто die уже некошерно?

exit/die?

слать хедер Connection: close ?

а для разных кодов возврата юзать 200 / 403 например.

exit — Output a message and terminate the current script. die — Equivalent to exit().

Вывод: некошерно.

слать хедер Connection: close ?

А точно nginx при этом разорвёт http-соединение?

а при terminate current script у тебя сеанс с юзером не закрывается? o_O

а при terminate current script у тебя сеанс с юзером не закрывается? o_O

Мне надо сначала закрыть http-соединение (закрыть сеанс с юзером), затем продолжить выполнение скрипта и только после этого убить скрипт.

хз, хедер close по идее должен говорить клиенту что типа надо-бы и разорвать коннект.

HTTP/1.1 defines the «close» connection option for the sender to signal that the connection will be closed after completion of the response. For example,

Connection: close

in either the request or the response header fields indicates that the connection SHOULD NOT be considered `persistent' (section 8.1) after the current request/response is complete.

меня тут смущает что «that the connection will be closed after completion of the response».

как вариант - можно принимать данные, складывать их куда-либо, и завершать работу скрипта. а другой скрипт, из крона например, или из incron'а, подбирает эти данные и обрабатывает.

а, ну, извини, не понял тебя сразу. Тогда как посоветовали выше - Header шли.

о, еще мысль пришла. можно же засылать данные не через обычную post форму, а посредством ajax, и на стороне сервера их процессить, не перезагружая страницу.

как вариант - можно принимать данные, складывать их куда-либо, и завершать работу скрипта. а другой скрипт, из крона например, или из incron'а, подбирает эти данные и обрабатывает.

Ну да, мне и пришла такая мысль... И сделать это через shared memory. Но хотелось бы простого решения :)

о, еще мысль пришла. можно же засылать данные не через обычную post форму, а посредством ajax, и на стороне сервера их процессить, не перезагружая страницу.

Вопрос не в перезагрузке страницы - вопрос в открытом http-соединении. А при Ajax'е http будет открыт столько же, сколько и при обычном посте.

Ну значит буду пробовать заголовки слать... Спасибо за идею :)

P.S. Этот скрипт не для работы браузера с сервером, а для работы двух компонентов системы, которые нужно связать обязательно по HTTP и серверную часть нужно писать обязательно на PHP. Такие пироги.

Нет, по Connection: close не получается.

Нет, по Connection: close не получается.

Что, в общем-то, и логично...

интересно, а что получится, если после приема данных, создавать форк посредством pcntl_fork(), и прибивать родителя через die() ?
в форкнутом процессе уже и производить всю обработку. умрет ли и форк, или станет зомби, или таки отработает?

http://stackoverflow.com/questions/138374/php-close-a-connection-early

интересно, а что получится, если после приема данных, создавать форк посредством pcntl_fork(), и прибивать родителя через die() ?

в форкнутом процессе уже и производить всю обработку. умрет ли и форк, или станет зомби, или таки отработает?

Думаю, что с форком можно реализовать, но тогда зачем мне FastCGI, если я всё равно при каждом запросе форкаться буду?

Ты же собираешься принять данные и обрабатывать их «потом», клиент не должен получить ответ в этом же соединении. Так объясни, почему ты так рвёшься делать это «потом» в том же самом скрипте? Положи данные куда удобно, а другой скрипт возьмёт их и обработает. Хочешь кроном, хочешь демоном, вариантов куча. И, думаю, вариант с общей памятью не слишком хорош. Вдруг ты захочешь разнести принимающий данные скрипт, сами данные и процесс обрабатывающий их на разные машины.

Ты же собираешься принять данные и обрабатывать их «потом», клиент не должен получить ответ в этом же соединении. Так объясни, почему ты так рвёшься делать это «потом» в том же самом скрипте?

Вообще это аргумент :)
Но дело в том, что данные очень сложно структурированы и парсить их два раза (первый раз: проверить валидность и сохранить, второй раз: получить и обработать) не хотелось бы.
Именно по этому у меня была идея с продолжением работы скрипта после закрытия http. Но вообще, видимо, лучше всего распарсенные данные сериализировать и положить в очередь, а после обработать демоном.

И, думаю, вариант с общей памятью не слишком хорош.

Это так, пример...

С форком работать не умею.

Но я бы сделал так:
1) Подготовил бы скрипт запускающийся из консоли (php-cli), который бы при запуске принимал один параметр из командной строки (имя файла). Из этого файла считывал сериализованный массив, и обрабатывал бы данные.
2) Принял POST-запрос
3) Сохранил бы пришедшие данные в файл на диске
4) Запустил бы скрипт (см. пункт 0) через вызов shell-exec("(script.php filename &) >> /dev/null 2&>1");
4) Отослал бы пользователю шапочку close с кодом.

Но я бы сделал так...

ИМХО вместо файлов лучше заюзать MemcacheQ.
А вообще, честно говоря, я не понял смысла предложенных действий :)

> А вообще, честно говоря, я не понял смысла предложенных действий :)

«Отпустить на волю» скрипт с длительной обработкой данных, а принимающий завершить с разрывом соединения. Хотя конечно некошерно, наплодится их...

> лучше заюзать MemcacheQ

Зависит от критичности потери части данных до их обработки.
MemcacheQ конечно хорош и стабилен, но... Выдернем сервер из розетки...

Есть вариант посложнее, чтобы файлы не юзать, и скрипты запущенные не плодить. Демон слушающий файловый сокет. Чтобы не затыкался на прослушке, операцию приема (accept) вынести из основного цикла. Принимать задания в очередь как между обработками, так и в процессе между шагами алгоритма.

Тут зависит конечно от скорости поступления заданий и скорости их обработки. Если разница велика, такого демона недостаточно.

MemcacheQ конечно хорош и стабилен, но... Выдернем сервер из розетки...

И у нас всё останется в BerkeleyDB :)

Ох, вот не любит наш человек доки читать, а любит придумывать сложные технологичные велосипеды. Прямо на главной странице php-fpm.org:

# Enhancements to FastCGI, such as fastcgi_finish_request() - a special function to finish request & flush all data while continuing to do something time-consuming (video converting, stats processing, etc.)

fastcgi_finish_request() - спасибо. То, что искал :)