Fwd: nginx FR: fcgi error handling

[Nick S. Grechukh]

---------- Forwarded message ----------
From: "Nick S. Grechukh" <gns@>
Date: Thu, 12 Apr 2007 20:24:14 +0300
Subject: nginx FR: fcgi error handling
To: mithraen@

предлагаю патчик для fastcgi модуля nginx, решающий следующую проблему:

Перехватить и обработать php fatal error средствами PHP в случае
фатальной ошибки невозможно - php уже умер, успев выдать сообщение в
stderr. в результате пользователь получает пустую страницу (или при
display_errors=on - сообщение от php), однако с кодом 200.

Во многих случаях это неприемлемо; под апачем mod_php выдает 500
Internal server error, что гораздо лучше. Насколько мне известно,
штатными средствами добиться от fastcgi+anywebserver поведения,
аналогичного модулю апача невозможно (intercept_errors здесь совсем ни
при чем).

Предлагается отлавливать эти ситуации анализируя stderr от fastcgi;
для этого введена директива fastcgi_catch_stderr, в которой можно
указать, какие строки в stderr следует обрабатывать как internal
server error. Мы используем fastcgi_catch_stderr "PHP Fatal error:",
но в принципе я постарался сделать не-пхп-специфичное решение.

Проблему я вижу только одну - если контент формируется постепенно и
часть ответа  уже попала клиенту, выставить код ошибки невозможно. Но
это понятно, с этим в любом случае ничего не сделаешь кроме полного
кэширования ответов fcgi (эксперименты показали, что в буфере nginx
помещается кусок до 4килобайт). А во-вторых, часто ответ кэшируется на
стороне php и в самом конце работы скрипта выдается целиком.

с уважением,
Nick S. Grechukh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nginx-0.5.14-gns-catchstderr.patch
Type: text/x-diff
Size: 2242 bytes
Desc: not available
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20070413/bfc973c0/attachment.patch>